How does a Cyber Security Audit work in practice?

The audit starts with preparation

I'll also request documentation. Think of network diagrams, application overviews, technical information and relevant policy pieces. For audits, baseline assessments and IT security investigations I work with a fixed documentation structure. It contains the research points, I can record evidence directly and during the audit step by step the basis for the reporting.

The scope determines what I can technically and organizationally examine. Therefore, I will make it clear in advance which environments, processes, locations and suppliers are part of the audit and which access will be available.

I keep looking at three things: what is agreed, what is told and what can I actually prove?

The first day of audit

An audit day usually just starts with coffee and get to know the people I need that day.

I plan interviews with employees, managers and key users. There is always someone who is responsible for IT and someone from management or management. Depending on the organisation, I also speak to application managers, internal IT staff and the external IT service provider.

In a multi-day audit, I try to start the technical investigations early. Network scans can then run in the background while doing interviews or viewing documentation.

I want to understand the environment. What systems are important? How was the network built? Is the network diagram still working? Is there actually segmentation? Which systems are accessible from the Internet? What gates are open? What vulnerabilities are visible?

Depending on the scope, I also log in to management environments. This could be the firewall or Microsoft 365 with an appropriate admin or viewer role. I'm comparing what someone tells me to how the environment is actually set up.

That makes an audit of this kind quite intense. I bring technology, processes, agreements, suppliers and physical security.

What's on paper and what I actually find

An important part is the tour through the building.

I look at server rooms, access protection, cameras, physical barriers and fire safety, for example. During such a tour you sometimes encounter things that are different than policy, procedures or interviews.

That's the difference that's interesting.

If on paper it says that a server room is always locked, but I see something else, that's relevant. The same applies when a process is formally well described and is carried out differently in practice.

I therefore keep looking at three things: what is agreed, what is told and what can I actually prove?

Suppliers are also included in the investigation.

Many organisations have a large part of IT with an external service provider. Then I can't possibly look at the internal organisation alone.

I therefore plan interviews with the IT service provider where necessary and request relevant contracts and agreements. Think of SLAs, DAPs, processing agreements and other service agreements.

What exactly was agreed? Who's responsible for what? Where does that say? And does the actual service link up with that?

This leads to important findings on a regular basis. Sometimes it appears that measures that the organisation thought were regulated are demonstrably not or insufficiently organised.

A supplier's ruling that something is regulated I do not think that is enough. I'm looking at facts and evidence. Also read how to control the selection of an IT service provider.

The audit is evolving during the days

The findings of one audit day often determine what I will continue to discuss the next day.

On the first day, I see what I'm missing. I usually judge collected evidence directly or the same day. That makes me aware of the points I want to verify the next day.

When I audit several days I therefore make my day planning based on what I found earlier. Sometimes a follow-up question comes a day later, sometimes only on the following audit day. That depends on the extent of the investigation and the number of days scheduled.

That's why I like to have plenty of time on site. When a customer is further away, I sometimes book a B&B nearby. That saves travel time and allows longer working hours.

And yes, I sometimes ask the dog to come. That is also a part of what a working day can actually look like.

Serious vulnerabilities I report immediately

Sometimes I come across something that requires immediate attention. For example, an unsafe open port on a firewall or a serious vulnerability on a server accessible from the Internet.

I'll call you in right away. The organisation will be given the opportunity to take action in a moment. If the solution is easy to check, I usually do a recheck afterwards, for example by rescanning or viewing the custom configuration.

The finding remains part of the report. I will record what I originally found, what evidence is included, that the situation was reported immediately because of the seriousness and that recovery took place during the audit. If I have been able to verify the solution again, I'll mention it.

This will keep the situation as it was originally during the audit.

Each finding gets its own proof

I report findings separately at a Cyber Security Audit. Even when several findings are about the same main subject, they remain isolated findings. Each finding is individually detectable and can therefore be targeted.

I use the BBRA method: Finding, Evidence, Risk, Recommendation.

The finding describes what I've established. If there is evidence, I shall record the basis on which that finding is based. At risk, I describe the possible consequences for the organisation.

The Recommendation describes initially where improvement is needed. Wherever that makes sense, I'm making the advice more targeted. Sometimes a solution is technical and the execution is with an IT service provider. I do not necessarily need to prescribe the complete technical design, as long as the desired result is clear.

The specific quantification of risks is part of a separate service. Within the Cyber Security Audit, I describe the risk to the finding without automatically making a full quantitative risk analysis. View the board-level risk analysis information security.

Baseline assessment, assessment and audit in practice

One Cyber Security Baseline Assessment gives a wide and relatively compact starting image. I look at the state of information security and look at the main strengths, vulnerabilities and improvement areas. The analysis remains broad, which makes it possible to combine observations in such a report.

One Cybersecurity Assessment deepen a defined technical, organisational or combined demand. I can also verify documents, configurations and other evidence in that respect. In a technical scope we set up the assessment as IT Security Assessment.

In a Cyber Security Audit I shall set out the criteria for the assessment in advance. I collect and verify traceable evidence, capture deviations separately and formulate an audit conclusion on the agreed scope.

This makes the audit report suitable for addressing findings and, where appropriate, for carrying out technical or organisational measures separately.

First all findings, then management reporting

During the audit, I make my notes as much as possible directly at the relevant research points in my documentation system. Evidence, observations and context are therefore immediately put together.

After the investigation, I will first work out the individual findings. I'll write the management report after.

During the audit, I sometimes make a note when I encounter something that I know deserves to be included in the management report. I want the complete picture before I draw the main line.

The management report mainly contains the findings that are important for management and governance. Serious anomalies, of course. Also, things that undermine the basis of digital security deserve a place there, even if the direct risk within a specific organisation may seem less at that time.

Besides, I'm looking at patterns. If I find several separate findings within one main subject, that often says something about the structural management of that subject.

What goes well is also part of the management report

In the management report I deliberately also mention what goes well.

What is more clearly regulated? Where did the organisation take steps? What else do I see when I'm in an earlier audit? And where does the organisation intend to go in the coming years?

An organisation that imposes high demands on its digital security will want to address certain deviations more heavily than an organisation with a different risk profile. An organisation that wants to digitize or become more dependent on IT will have different priorities than an organisation that changes much less.

The audit provides the facts. The ambitions and risk appetite of the organisation also determine which choices are then wise.

Concept phase: facts, context and views

My reports always go to the customer as a concept first.

Then I'll discuss the report with the people involved. These can be boards and executive management, IT and other responsible people.

I'm always curious about their views. There may be relevant contexts I haven't known yet. It is also possible to look at the significance or priority of a risk.

A demonstrable finding remains in place when the evidence supports that finding. If evidence shows that something is not well-equipped, that is the observation. The discussion then deals with the context, the significance of the risk and the priority the organisation gives it.

The same applies in conversations with external IT service providers. I'm sticking to what the facts and evidence show.

An audit report shall be regularly interviewed with the IT service provider.

Many audits do not show sufficient evidence of the regulation of parts of an external IT service provider.

This can show that expectations and reality have started to break up, even when other parts of the service function well.

An audit report is therefore regularly used as a factual basis for a conversation with the supplier. What points do recovery require? What agreements do you think deserve tightening? What service was agreed and is it actually provided?

Sometimes the research confirms a feeling that existed in management or management: that the cooperation is not working well or that confidence is decreasing. The independent investigation shall make clear which concerns are factually substantiated.

Therefore, a second more substantive report is regularly requested in addition to the management report, which includes the findings specifically concerning the external IT service provider.

The discussion varies by target group

Usually a customer wants to go through the draft report quite completely. Things that are already clear I walk by. In the case of questions or differences in interpretation, I take the time to explain the evidence and my assessment.

I often have a different conversation with the board and management of larger organisations.

Then it's less about one firewall setting and more about questions like: How did this happen? What risks are not adequately controlled? Why wasn't this visible before? What decisions are needed now? Where is budget priority? And what does this mean for the digital future of the organisation?

That is where the value of management reporting lies for the board and executive management.

Comparing recurring audits is becoming increasingly valuable

If I audit an organisation more often, I'll deliberately compare the new situation with previous years.

What points have been resolved? Where has progress been made? What findings are coming back? And what recommendations have been made before and still haven't been taken?

This can be improved because my own services have also been developed over the years. I use a fixed working method and a documentation system that consistently records research points and evidence.

That's why I can compare apples to apples. A repeat audit shows more and more clearly whether the organisation is actually progressing.

When will the audit be ready?

For me, the Cyber Security Audit is completed when the final report is completed and the final discussion has taken place. Then it can stop. That's not often.

Kynexis is regularly asked to draw up a prioritized improvement plan and to accompany its implementation. Sometimes we write or update policies, we put policy pieces in order better or we help implement a Digital Safe Work Handbook, for example.

If trust in the IT service provider has really disappeared, the question may also be to help in selecting a new service provider and to set up the transition path.

Another step can be an board-level risk analysis. Especially when the audit showed that governance and management thought things were better organised than in reality.

These are separate follow-up assignments. The audit itself was completed after the final report and the final discussion.

What does an organisation have in its hands after the audit?

At the end, I want to be clear.

Any quick wins are visible. The organisation knows what it can pick up first in the next three months.

the board and executive management can make more conscious choices about priorities, investments and projects. Budgeting is being more targeted and better substantiated.

The organisation is more involved in discussions with IT suppliers and other service providers, because there are independent and objective facts on the table.

That's where I want to get the audit: management and governance have independent facts in their hands, can prioritize and better determine where time, money and attention go. This helps to steer more consciously on the digital future of the organisation. Read more about Wouter Parent and his method.