Considerations when getting started with InfoSec policy.

31 Aug, 2023

Policy work is one of the most reliably 'second-hat' pieces of work that I've come across in industry for smaller organisations. I've spent countless hours with people who have very little interest in policy who have clearly been saddled with the job of getting org policies sorted out. I've seen the populated templates that they work very hard to get across the line and signed off by the board, and I know the line of questioning that can very quickly unearth whether a policy is anything other than 'shelf-ware'.

This speaks to a few conversations; where should policy sit in the emergent or organic growth of smaller, modern businesses? How have we developed a common sense relationship to policy that limits our understanding to be purely about the ticking of legal boxes? Is there any way to develop meaningful, useful policy that doesn't get you absolutely lost in SEO-engineered advertorials along the way?

I want to cover some of this here, and provide a meaningful conversation that I truly believe will enhance whatever policy drive your org is on right now. Thinking about these things for the sake of thinking about them certainly guarantees a superior design, and hopefully might even change the relationship you have with the process.

Policy work can feel like nothing less than the articulation of the complex social and procedural relationships between members of the org, but this requires a renewed focus on policy as a social toolkit, not a punitive or legally mitigating collection of rules.

Who is this for?

Anybody who has taken on (or been handed) the responsibility to sit down and assess, rework, develop, or otherwise work with the body of policy of their organisation. Business Continuity, Information Security, Acceptable Use, BYOD are in-exhaustive examples of what may be on your plate at the minute.

Why am I positioned to contribute to this?

I have run Gap Analysis projects for many organisations across many disciplines. I review bodies of Information Security and Business Continuity Policy in accordance with internationally recognised standards ISO 27001 and ISO 22301 - providing considerations for orgs to take to their future discussions to enhance their policy. I'm also an accredited ISO 27001:2022 Lead Implementer under the British Standards Institute.

I am not sitting down here to tell you how to run your business or what requirements you categorically need - Context is the precursor to knowledge and I don't know yours. I am collecting my (ongoing and developing) personal experience of this side of InfoSec and sharing it in the belief that it will be useful to someone.

What is to be covered?

• What policy is, and what policy isn't
• How to get started on your policy
• Signposting resources for your consideration (UK)

📑 What is policy?

I've written using the term 'policy' as a broad classification of the work that may be coming as part of (in-exhaustive):

• Implementing Information Security policies/ Cyber Security Policies
• Documenting or building out your Business Continuity Policy or plan
• Building an ISMS, or a BCMS
• A drive to put knowledge into organisational ownership that currently sits in people's heads, or in the 'common sense' of the org.

Looking at the commonalities between these examples (or indeed your unmentioned but incredibly relevant example) is useful in helping us define what 'policy work' should look like.

At its most simple, Policy refers to a system of guidelines that are used to achieve desired outcomes. People build these systems when they work in collaboration with other people so that they can be consistent over time and meet shared objectives. If people work collaboratively for a shared output of some kind, it’s important that they agree on a process. Processes are the efforts we take to meet objectives or goals. We determine what processes are by using ‘inputs’. Inputs can be things such as conversations, shared objectives, or requirements.

Examples of inputs could be the marking scheme for a group project, or the mission statement of a charity. We need these to figure out what we want to achieve (Outputs), and how we want to achieve it (Processes).

When we follow through with our efforts and create something based on our shared goals, we have produced an output. We can then assess whether our output is useful by comparing it against our intentions when we determined our inputs.

While this process can be done in a conversation for a group project of three people, it gets harder to ensure that processes are agreed upon if you bring more people to the conversation. When a project between two people turns into a collaboration between ten, it starts to become easier for different people to have diverse opinions and priorities on our inputs, our processes, and what our objectives are.

Policy helps us to collaborate at larger scales by documenting what our objectives are, what inputs inform those objectives, and what processes need to be followed to make sure those outcomes happen.

Our body of policy needs to accurately map the relationships between people, and provide an accurate signpost to the resources that mark out subsequent roles and responsibilities. These must be justified in a way that can be walked all the way back to the strategic objectives of the organisation, which themselves can be justified as considered and informed.

🗺️ TL;DR - Policy cannot be used simply to mitigate risk or answer to regulators. Policy should be used to map the relationships between people, and the subsequent agreed (and existing) processes that create and describe how business objectives are used to make decisions on risk and controls in your business. Policy is a map to processes.

👁️ ➡️ 🧠 Make the descriptive explanatory.

Further to the previous point - if you are developing a management system of any kind and intend to map or articulate that system through a body of policy, it is vital that the system is explanatory, and not just descriptive.

Description is the account of traits or features of a given object that can be used to identify it. Explanation is the ability to decompose and identify the mechanisms by which the describable actually comes to be and operate.

It is not enough to create controls that are only descriptive, it is important to show the provenance of any responsibilities or controls and draw a silver thread back to the underlying mechanisms and processes that justify and explain this final output. This can be seen as an explanatory relationship.

🐦 The Stress Canary

Policy work should not by its nature cause stress. The concerted effort to capture and document the relationships between different operations and staff is a project that will make life easier. Each stage should bring relief and clarity to your mind about the state of the business, and the opportunities for further development. But the scale - or the information, that you uncover about the readiness of your organisation - alongside improper resourcing or support, can leave you feeling like you're clutching at straws or doomed to fail.

Stress should be seen as a Miner's Canary for the methodology of your project. Ensuring you are following a process that has been informed and approved by top management means you cannot feel lost, and should not feel stressful. If you do catch yourself feeling stressed, you need to remember that:

• You are not taking on ownership of the risks you are identifying, and they exist with or without your knowledge of them.
• Policy work can only arise to document what organisational objectives and goals have been determined, it is not your job to create as you document. These are separate work streams (More on this later).
• If you are a risk owner also completing the policy drive (likely a micro or small business owner), then make sure you're separating the creation of new processes/goals from the documentation of them in policy. That degree of separation will stop you going mad.

🍰 Working guidance for development of policy - The short version

The main takeaway from what has been said so far is that policy must serve to articulate existing decisions and processes, not create them from nothing. In practice, it is almost universally applicable advice that:

1. Any body of policy that creates obligations should be based on a risk assessment and impact analysis.
2. Risk assessments and impact analysis should consider the strategic goals and objectives of an organisation.
3. Strategic goals and objectives are set by top management.

You can take this waterfall of responsibility to the bank and stop reading now if you like. The reason policy is so vital to any management system is because it serves to articulate an explanatory relationship between these key features. Policy is the output of a management system, not an input.

Consequently, some of the best policies I have ever reviewed have been 1-2 pages long, and some of the worst I have ever seen have been long, arduous, and control-centric.

A note on inputs and outputs in the context of continual improvement: Cycles of iterative and continuous improvement eventually do mean that policies become an input for a process seeking to refine and enhance the management system of your choice, but it's not always useful to begin with this mentality, and it may in fact hinder the important appreciation of policies being the documentation of processes that exist, instead of the conjuring of new processes as they are written.

Some Reflections on good practice for policy projects

👍 Identify the work-object and get buy-in

The first step on any high-level/organisational project should be to secure buy-in from top management. This is the acknowledgement and resourcing to commence your project. Traditionally we're thinking about the board or the C-levels here - but realistically it's likely to be the person who pays for things to happen, and goes to prison if they violate the companies act. As we are looking to create a body of policy that derives from strategic objectives we need to get authorisation for those responsible for setting them. If a project such as this doesn't have meaningful and well-resourced buy in then it's a non-starter.

What does buy-in need to be for? It cannot simply be for the development of our policies in house, as policies develop as a by-product of meaningful decisions that lead to new processes or management systems.

So the real work that is being proposed is for the development of:

1. Mechanisms to identify what processes are necessary for our ISMS
2. Commitment to the refinement of the processes we already have in place
3. Resourcing and support for the new processes or procedures that are required
4. Effective documentation of this work in a body of policy.

Let's now discuss setting information security objectives. We derive IS objectives from common information security goals that are considered to protect or develop the overall strategic objectives of the organisation. These let us focus on how we technically assure information security using policy, processes and procedures. We also use them as a unit of measurement in the establishment of our risk appetite - as we can ask whether certain actions support or damage our information security objectives.

Another way I have tried to visualise this is seen below, where we place our Information Security Objectives within our strategic objectives. The respective objectives are our measures of whether we have enacted our day-to-day processes (such as the mentioned ad campaign or awareness program) in accordance with our overarching objective.

Either way, the essential concept being communicated is that we have specific goals we set using our IS Objectives, which themselves are set as supporting concepts for meeting our overarching strategic objectives.

🧱 Design Information Security Objectives based on the CIA Triad. These are your 'raw materials'

Information Security objectives are very easy to set and tend to be similar for different organisations. They get more specific or convoluted mainly when we need to take on certain levels of risk that change how we protect information. For the most part, we create Information Security Objectives as a means to focus on how we technically assure the information security of an organisation to better support the overall strategic objectives

you can safely use the following guidance:

Information Security objectives can almost always derive from the CIA Triad - Which is the confidentiality, integrity, and availability of data. When we set out these objectives we create the mechanism by which we justify new roles, responsibilities, and processes. These IS objectives can be as simple as:

The organisation appreciates that the maintenance of Confidentiality, Integrity, and availability as pertaining to information and information systems is integral to the support of the strategic objectives of the organisation. we therefore create the following Information Security Objectives:

1. To implement, maintain, and continually improve our information security to better protect the confidentiality of our information, including but not limited to sensitive information.
2. To implement, maintain, and continually improve our information security and design to ensure that the integrity of our information and information systems remains unquestionable.
3. To implement, maintain, and continually improve our information security and design to ensure that the data that we rely on - and the people that rely on us, are able to access the data they need in a timely and reliable manner.

With these three core aspects of the CIA triad folded into the objectives of the organisation, you have created the means by which controls and responsibilities can be explained and justified. These are the raw materials from which we can build more precise or granular controls and processes.

✅ Figure out what you care about - Start with a risk assessment

When we tell users to use MFA or a password manager, or what is expected of them when taking care of a company owned laptop, we are supposed to be making an informed decision in response to a risk.

We should theoretically only be able to take these precautionary actions after qualifying the actual risk we are treating. In the 'real world' we don't need to fully qualify the likelihood or impact of risk when we decide not to throw ourselves from great heights or ingest unknown berries, so it can slip our mind to qualify risk when we are building systems of work.

Building management systems are very different to the rough and ready risk calculations we conduct when regarding our own physical safety - we are creating a system by which we must justify the obligations we place on other members of our organisation, and a system whereby these obligations support loftier and further reaching strategic objectives. We therefore need a mechanism to assess risks before treating them. This is what a risk assessment is.

A risk assessment consists of identifying what may interrupt the successful ongoing enactment of strategic objectives, and then weighing up the likelihood that this incident may occur, against the impact that this incident would have if it did occur. Once we identify and qualify the major and minor risks facing the business, we are able to make an informed decision about what we can do to treat these risks and protect our strategic objectives.

Conversely, if we try to build out a set of controls or requirements without a risk assessment, we do not have any underlying structure to justify or measure the success of the control. This is not a suggestion to create measurement and performance tracking where there is no need to, only to create a relationship with risk whereby we need to be able to articulate it fully in order to say with certainty that we have treated or addressed it.

🗺️ Figure out who cares about you - Look at your context

Management Systems place a lot of focus on 'understanding the organisation and its context'. This refers to the need to be able to place your organisation within the landscape that it acts and behaves in. The interconnected nature of different economic and social forces is one of the requirements for an organisation to even be possible to run and exist; It makes sense that we can't abandon the consideration of these factors when it comes to securing and protecting our organisation.

The two points of interest for considering context are to:

1. Understand your 'context' using a focus on internal and external issues that may affect your information security management system
2. Understand the needs and expectations of people or organisations that you are connected with

I'll attach a table with some examples of internal and external factors for consideration, but the best rule of thumb is to find and categorise issues, individuals, and institutions into either internal or external factors, and run a thought exercise where you identify how these things may impact your strategic objectives.

A note on the scope of consideration: It's not just legal/good faith actors you should consider as a part of your context. Criminals or those who would see harm to your organisation should also be considered in this process. Any 'Issue, Individual, or Institution' really does mean anyone and everyone.

🏠 Build the house before you live in it (Even if you live in it already)

Any structured management system/body of policy project should have clear demarcation between the planning and operating phases. Planning is the process by which we determine and begin measuring objectives, whilst ascertaining what risks we are identifying and what our approach to treating them are. Operation is actualising our plans, and can only ever be done properly if we are working to a good and thorough plan.

This may seem like common sense - but I feel I must make this point as I have seen a very common approach whereby the project owner (who is unfortunately likely doing the work because they have been told to, not because they want to) will put together a set of boxes to tick and processes to change or conjure into being, and work from the operation of the organisation backwards, and create documentation of processes as a byproduct of the unjustified sets of controls they just 'feel' should be in place.

I can't emphasise enough the ongoing help that a thorough planning phase will provide.

💭 Closing thoughts

I hope you've enjoyed this collection of thoughts on policy and management systems, and I hope someone finds it useful. It is of course in-exhaustive and there is plenty more to talk about - Which I hope to do. This feels like a good portion for thought however, so I will leave it here for the moment.

The main takeaway I hope to provide is that it's worth digging into thinking about this stuff from an architectural point of view, and giving yourself as much breathing room as you possibly can to discuss and design the process for your policy work. If you have ended up using this piece of writing as a contributing factor in your project and you'd like to chat further about it's application in your specific business context then let me know (savva@pistolas.co.uk). You can also subscribe to my blog via email or RSS feed.