From controls on paper to verified security – assurance

From controls on paper to verified security – how to work with assurance

How do you know your security controls actually work? On designed, implemented and operationally effective controls, evidence without administration, and risk-based control testing.

Summary: A security control described in a policy is not the same as a control that works. Assurance is about moving from documented controls to verified security: distinguishing between designed, implemented and operationally effective controls, testing the right thing in the right way, building evidence into the control rather than hunting for it afterwards – and starting risk-based with the controls that matter most.

Most organisations can answer yes to the questions:

  • “We have MFA.”
  • “We have backups.”
  • “We have access control.”
  • “We have an incident process.”
  • “We have supplier controls.”

Good. But during an audit, a supervisory review, a customer assessment or an incident, the next question comes: Can you show it? And then the even harder one: Does the control actually work – all the time, for all systems, for all users?

That is where assurance begins.

Three levels that are often confused

1. Designed control

The control is described. The policy says all administrator accounts must have MFA. There is a procedure for access reviews. There is a backup instruction. This is necessary – but it says nothing about reality.

2. Implemented control

The control has been put in place. MFA is enabled in the identity platform. The backup jobs are configured. The access review has been carried out once. This is a step further – but still a snapshot.

3. Operationally effective control

The control works over time and does what it is meant to do. MFA applies to all privileged accounts without exception, including those created last week. The backups complete, restoration has been tested and works within the time the business needs. The access review is performed every quarter and actually leads to incorrect permissions being removed.

It is this third level that an auditor, a supervisory authority or a major customer wants to see evidence of. It is also the level most organisations find hardest to demonstrate.

Test the right thing

Different controls need to be tested in different ways. A common mistake is to test every control with the same method – often by asking someone whether the control exists.

  • Technical control – verified against the system itself: configuration, logs, export lists, automated reports. The question is not “do you have MFA?” but “show me today’s list of privileged accounts and their MFA status”.
  • Manual control – verified by sampling that it has been performed: approvals, signed reviews, tickets, meeting minutes. Was the access request actually approved by the right person before the permission was granted?
  • Periodic control – verified by checking that it has been carried out at the right frequency, by the right role, and that deviations were handled. A quarterly review performed twice in a year is not operationally effective.
  • Governing control – verified by confirming that policies, roles and decisions are current, communicated and approved at the right level. Is there a management decision on risk tolerance, and is it followed?

Take backups as an example. The backup job running is an implemented control. It running every night without errors is a partially verified control. Having actually restored a critical system from backup, measured the time, and confirmed that the data was complete and usable – that is operational effectiveness. Many organisations have never taken that last step.

Evidence should support the control – not create administration

A common scenario before an audit or supervisory review is the evidence hunt. Someone spends weeks searching for:

  • screenshots from various systems
  • old email approvals
  • minutes from meetings held six months ago
  • export lists nobody saved
  • test reports that may exist at the supplier
  • logs that have already been rotated away

It is expensive, stressful and rarely produces a complete result. The alternative is to decide how the control will be evidenced at the time it is designed. Five questions go a long way:

  • What evidence shows that the control works?
  • Where does the evidence arise – in the system, in a ticket, in minutes?
  • How often does it need to be collected?
  • Who is responsible for making sure it exists?
  • How long should it be retained, and where?

When evidence is built into the control, it becomes a by-product of normal work – not a separate project every time someone asks.

Follow-up is becoming more important

The requirement to demonstrate – not merely claim – is increasing from several directions at once. In its methodology guidance, the Swedish National Cyber Security Centre (NCSC) highlights follow-up and evaluation of security measures as a distinct part of systematic information security work. It is not enough to introduce measures; the organisation must also verify that they work and adjust them.

For organisations affected by the Swedish Cybersecurity Act, this becomes concrete through the regulations issued by the Swedish Agency for Civil Defence (MCFFS 2026:11 and 2026:12), which apply from 1 October 2026. They require security measures to be followed up, evaluated and documented – and the supervisory authority must be able to obtain supporting material on request. Similar requirements already exist in DORA for the financial sector and in ISO 27001 through the requirements for internal audit and management review.

What they all have in common: a policy is not a sufficient answer.

Assurance is not the same as a gap analysis

The two are easy to confuse. A gap analysis answers the question: Which controls are missing or incomplete in relation to a requirement? It compares the current state against a framework and produces a prioritised list of what needs to be built.

Assurance asks different questions about the controls that already exist:

  • Is the control implemented as designed?
  • Does it work consistently over time?
  • Does it cover the full scope – all systems, all users, all suppliers?
  • Is there evidence that an independent party can review?
  • Are deviations handled when the control fails?

The gap analysis comes first and shows what needs to be built. Assurance comes afterwards and shows that what was built holds up. Organisations that only do the first get a nice action list but no certainty.

Start risk-based

Nobody can test every control all the time. So start with the controls where a failure would do the most damage and where you currently have the least visibility. For most organisations that means:

  • privileged access and administrator accounts
  • backup and actual restoration capability
  • incident detection – do you notice what is happening?
  • critical suppliers and their controls
  • protection of backup copies against tampering and encryption
  • patching of internet-facing systems
  • manual processes that depend on individual people
  • regulatory reporting – can you report on time if something happens?

Then expand testing gradually, with an annual plan driven by risk – not by which control happens to be easiest to test.

How Kristensson i Skåne can help

We approach assurance and internal audit as independent, practical verification – not as a paper exercise. Depending on your needs, we can contribute with:

  • internal audit of information security against ISO 27001, the Swedish Cybersecurity Act, DORA or your own requirements
  • control testing of design, implementation and operational effectiveness
  • evidence review and design of evidence collection
  • maturity assessments
  • audit readiness ahead of certification, supervisory review or customer assessment
  • sampling and recurring checkpoints
  • third-party assurance – reviewing critical suppliers’ controls
  • follow-up of actions from earlier reviews
  • Assurance-as-a-Service – ongoing, planned control testing throughout the year

The goal is not more documents. The goal is for you to be able to answer “yes, and here is the evidence” – before anyone else asks the question.

Want to know whether your controls hold up? Read more about our assurance and internal audit services or contact us for an informal conversation.

Sources: Swedish National Cyber Security Centre (NCSC), methodology guidance for systematic information security work; Swedish Agency for Civil Defence (MCF), regulations MCFFS 2026:11 and 2026:12, applicable from 1 October 2026; ISO/IEC 27001:2022, clause 9 on performance evaluation.

This text is general information and does not constitute legal advice in an individual matter.