How to deliver cybersecurity assessments

Types of cybersecuity assessments

What does it mean when an organisation says they want a cybersecurity assessment? This is actually a very complicated question to answer.

• •There are so many different types of cybersecurity assessments
• •Within each type, there are so many different frameworks you can use

But the most difficult challenge by far is that the person who asked for an assessment may not know themselves what they want. They often haven't fully considered what action they want to use your assessment to deliver.

Part of the problem is that there is so much confusion about what "being secure" even means. Does it mean you won't have any major incidents, or that you will, but you're prepared to handle them? Does it mean you won't fall afoul of cybersecurity regulations, or that you're spending the same amount on cybersecurity as all your competitors do?

In the table below, I've listed the most common types of cybersecurity assessments, and tried to illustrate why they are used, what they achieve, and what their limitations are.

It should be fairly obvious that there really is no "one size fits all" approach!

My advice is to focus less on the request you get (i.e., "I want a cybersecurity assessment") and more on the business context of the organisation.

For example, if your client is an SMB or a Mid-Market firm, then they are primarily looking for advisers and partners. This means you can take some liberties, and your focus should be on delivering guidance rather than rigidly adhering to a type of security report or framework. If a Mid-Market firm asks you to deliver a Service Maturity assessment, that absolutely does not mean they are not highly interested in control effectiveness as well, and you should consider trying to cover as many bases as you can.

This has happened to me many times over the years. A client asks me to deliver a NIST CSF assessment, I do, and then they ask what their biggest risk is... But of course, NIST CSF is a Service Maturity framework and not a Risk assessment framework! Clients in this market category will routinely ask for one thing and expect another. Be prepared for that.

There is one singular golden rule I live by, and it's this: Cybersecurity is not about having controls, it's about having appropriate controls for the commercial context. There is no such thing as "100% secure", there is only risk exposure and the resources you have available to mitigate that to an acceptable level.

Delivering your engagement

This post does not address how to sell cybersecurity assessments, only how to deliver them. We'll assume that you already have one to deliver. However, if you're interested in a forthcoming article about how to sell these engagements, you can submit your details here. We'll be publishing that shortly.

Regardless of the type of assessment you are delivering, or the framework you are adhering to, your engagement should almost always involve the following stages.

• •

  Document Review. Send out a Document Request List at the start of the engagement and request a large range of information (cast a wide net).

• •

  Questionnaires. Gather the basic or preliminary information you need to contextualise the engagement and lead a strong interview (establish the critical context).

• •

  Interviews. Get the right stakeholders together to explore more complex topics and dig into the details (hone in on what matters).

• •

  Presentation. Deliver your findings to your client and answer their questions before handing over the full report (provide solutions to their problems).

We'll look at each of these stages in the sections that follow.

Document Review

I have a bit of an industry secret to share about document review, and hopefully this doesn't shock too many readers.

Most engagements don't charge enough money for the consultants to do a full document review. Most of what you send them gets ignored. An organisation could easily have over 100 different policies, plans, procedures, certificates, and scans. We simply don't have the budget to review all of it.

So why is it such an important part of the process? It accomplishes several critical things:

• •

  It allows you to send your client an actionable Document Request List as soon as the engagement comes in, giving the impression that things are moving ahead at full steam and you are ready to deliver.

• •

  It forces your client to think about whether these documents actually exist. You put them in a headspace where they start to think critically about their gaps, and this means that their concerns will be easier for you to surface.

• •

  It's a quick measure of the client's maturity. After you have read 10+ Incident Response policies, you will know that they basically all say the exact same things. The contents of the policy matter far less than the fact the policy exists, because it demonstrates that at some point someone in the organisation has said, "we need an Incident Response Policy". And that's very valuable information. If there's no policy, it's because no one has taken the responsibility to get it done.

• •

  You simply never know what might be relevant, and it's absolutely good practice to skim over whatever documents a client sends and decide whether or not it's worth a closer look. In particular, you will definitely want to review any historical cybersecurity assessments they might have completed.

I've compiled the standard Document Request List I use for all engagements, and you can download it below.

Questionnaires

The questionnaire you send should be standard and focused on establishing the basics. If you have a pre-existing relationship with the client, fill out as much as you can in advance. People typically dislike filling out forms, so they will appreciate anything you can do to make it easier.

There are a few simple guidelines I try to stick to when sending out questionnaires:

• •

  Keep it all under 50 questions; aim for 40.

• •

  Avoid open-ended questions. You can explore exceptions later, instead try to focus more on whether a simple capability exists (e.g., is there an EDR agent in the environment).

• •

  You don't need a flashy tool, especially when only dealing with 1-2 stakeholders. Excel is fine.

The questionnaire I use most often is included below. It's a good starting point, with 33 questions in total, divided into 7 categories.

Reviewing the responses

Once you receive the response, I typically review it by following the process below.

1. •

   Start by carefully reading through all of the responses. Focus on obvious control gaps (such as lack of MFA, no EDR, or untested backups), historic incidents, and lack of governance (e.g., no risk registers).

   Take note of any patterns or trends that emerge, for example, saying that a control is "planned" or "under review". Stakeholders will often use terms like this to soften the implication that the control isn't deployed. But if you see that many controls are described in this way, perhaps it's a red flag.

2. •

   Focus on the coverage of a control. For example, sometimes organisations may not deploy the same EDR agent to both servers and workstations. How would this impact their ability to detect security events spanning both environments? Does two different products indicate a split strategy, or are there legacy reasons?

3. •

   Don't take the client response at face-value. Be skeptical, and consider that they might not know if their control is as effective as they think.

   • •

     How would the organisation know if their backup service actually works? When was the last time they attempted a restore?

   • •

     How do they know that all their users have MFA deployed, with no exceptions? What about outside of their M365 ecosystem, like VPNs, or SaaS solutions?

   • •

     Who has responsibility for controls to make sure that they continue to operate effectively?

   • •

     Is the control supported or maintained by an outsourced MSP or MSSP?

Interviews

This is my favourite part of the entire process. It's where you get to demonstrate the most value and be creative in how you uncover the full story.

This is not a place where you can read questions off a list and ask for answers. That's why we use the questionnaire. For interviews to be effective, you need to have a genuine conversation with your stakeholders. This is your chance to understand more about their company culture and why things are done the way they are. Be prepared to listen and improvise.

The biggest single piece of advice I can offer, and where I see many younger consultants and analysts trip up, is this: be kind! Security is a culture, and that culture is driven by education and awareness. Every organisation is on their own unique journey towards resilience, because resilience is what will ultimately protect their commercial venture and ensure its continued success. Help them understand this, and you will get strong engagement from them.

If they haven't been patching, if they're missing key controls... this is not something to attack or criticise, its a chance to nurture.

Because it's so important that interviews are delivered naturally, I don't like to prescribe any hard rules. However, there are few guidelines that you might find helpful.

• •

  Forget everything about cybersecurity. Remember how I mentioned that cybersecurity is only useful inside a commercial context? Get them talking about their company, what it does, how it makes money, where its located, and how technology is used to support their delivery model.

  You will find that once they start talking about how their business works, you will quickly form some extremely relevant questions about what steps they take to protect their business.

• •

  Focus on the top-level governance. More likely than not, if an organisation has implemented an effective governance structure, standard controls will be implemented and effective. To understand what that governance structure is, consider:

  • •

    What is the top-level governance body? This will often be a CEO, group of executives chaired by the CEO, or a Non-Executive Board.

  • •

    Does this top-level body regularly receive cybersecurity updates? In what form?

  • •

    Does this top-level body maintain an enterprise risk register (note: this is not the same as a cybersecurity risk register)?

  • •

    If they do all these things, consider asking how they know that the risks they're presented with are accurate and reported consistently. How do they have confidence that their CISO has properly calculated their risk?

• •

  Focus on roles and responsibilities. Cybersecurity is typically spread across operational roles (e.g., alert triage, training & awareness, control configuration) and strategic roles (e.g., GRC, control design). What types of roles has this organisation defined, and how are they resourced?

• •

  Control deficiencies do not mean that their cybersecurity is bad! Cybersecurity is not a box ticking exercise, and it's often incredibly difficult to implement a new control even when you know there is a gap.

  If you spot an issue, start by asking the organisation about their plans to address it. Weigh their response against the resources they have available, their operating culture, and the history of the organisation. Have they got a track record of delivering items on their roadmap, or are there underlying areas where they need more support?

• •

  Poor cybersecurity is rarely the result of one person's actions. If organisations invest in cybersecurity, it matures. When budgets are inflation-adjusted only or fall in real terms, cybersecurity declines. It really can be that simple.

  Return on investment keeps everyone accountable, so consider how budget and resources relate to any current issues and think about how you weave that into your reporting narrative.

Although I said that I don't like to be prescriptive about how interviews are conducted, I do have a template checklist that might help get you started. However, I'd encourage throwing it away as quickly as possible! You can download it below.

Presentation

You can lead the strongest engagement, conduct the deepest dive into their controls, and uncover critical issues. But it's all pointless if you can't communicate the "so what" to the client.

Presenting your findings has nothing to do with cybersecurity. It's about spinning a convincing narrative, providing reassurance, and opening up the opportunity for them to partner with you in the future.

You'll also mostly be speaking to an executive audience. The full report will have a wider distribution, and you'd expect a lot of the interested stakeholders to have technical backgrounds. But when you're in front of the senior decision makers, you need to speak their language.

In my experience, there is only one thing that executives want to know: Do I need to invest more money? The details don't matter so much to them, their job is to control resource allocation. The rest is someone else's problem.

This means that you need to distinguish between two types of issues:

• •

  Issues that can be addressed using existing organisational resources. That is, something that existing teams or vendors can fix within current budgets.

• •

  Issues that require some sort of additional investment. Perhaps that's more team members, additional tooling, or upgrading service levels with a vendor.

Here are some examples how I would summarise a report to an executive:

This isn't to dismiss the fact that your other findings won't be significant or interesting. If you have done risk assessments, or calculated service maturity levels, an executive stakeholder will certainly want to see and understand this content. But you should be using that information to reinforce and evidence your key takeaway, not make it the main event.