Control testing that doesn't waste anyone's time

Stop Testing for the Sake of Testing

In my two decades of auditing, the most common failure I see isn't a lack of controls, but a lack of 'auditability'—the ability to prove a control worked at a specific point in time. If you have to spend two weeks 'prepping' for an audit, your testing regime has already failed. You are not building a library of screenshots; you are building a verifiable history of operational discipline. This requires a shift from manual oversight to an evidence-first mindset where the process itself generates the proof.

Clause 9.1 of ISO 27001 specifically demands that organisations evaluate the security performance and effectiveness of their ISMS. This isn't a suggestion; it is a core requirement of the standard. To meet this without losing your mind, you must define exactly 'how' you will measure each control before you even implement it. If a control cannot be tested objectively with a clear pass/fail outcome, it’s probably a policy, not a control, and you should treat it accordingly.

The Four Pillars of Effective Evidence

Not all controls are created equal, and your testing methods shouldn't be either. For technical controls like disk encryption or MFA, manual testing is an expensive joke; these should be verified via automated scripts or API calls. However, for 'soft' controls like management reviews or incident response post-mortems, you need a more qualitative approach that focuses on the substance of the discussion, not just the existence of the meeting minutes.

I categorise testing into four distinct buckets: inquiry, observation, inspection, and re-performance. Inquiry is the weakest form of evidence—asking someone if they do backups—and should be used sparingly. Re-performance is the strongest; if I can't replicate your 'secure' build process using your documentation, then your control is essentially a myth. Balance these four methods to satisfy the 'appropriate' requirement of Clause 9.1 without over-complicating your life.

• Statistical sampling: Using the 'Square Root of N + 1' rule for large datasets to ensure representative samples.
• Direct Observation: Watching a developer perform a production deployment to verify segregation of duties.
• Re-performance: Having a GRC lead attempt to follow a documented offboarding process to see if it actually works.
• Inspection: Reviewing system-generated logs or signed-off change requests for specific attributes.

Risk-Based Frequency: A Better Way to Schedule

A common mistake founders make is trying to test everything every month. This leads to 'compliance fatigue' and inevitably results in people pencil-whipping the results. Instead, tier your controls based on risk. Your 'Critical' controls—those protecting your primary data stores or managing privileged access—should be tested quarterly or even continuously. Your 'Secondary' controls, like physical office security (which matters less in a remote-first world), can be tested annually.

Your testing schedule should be a living document, not a static spreadsheet. If a specific control, such as your joiners/leavers process, keeps failing, the frequency of testing must increase until you see three consecutive 'clean' cycles. This demonstrates the 'Continual Improvement' required by Clause 10.2. It shows the auditor that you are actually using the data from your tests to manage the business, rather than just filing it away in a folder.

The Anatomy of a High-Quality Workpaper

The 'Workpaper' is the basic unit of work for any internal auditor, yet most small firms skip it entirely. A good workpaper should allow an independent person to reach the same conclusion as the tester without needing to ask any questions. If your evidence for 'User Access Review' is a single email saying 'Looks good to me,' you will get slaughtered in a Stage 2 audit. You need to show the list of users reviewed, the date it happened, and the specific actions taken for any revoked accounts.

Standardise your evidence collection. I advise my clients to use a 'Single Source of Truth' for evidence—whether that's a dedicated GRC platform or a locked-down repository. Avoid the 'Desktop Artifact' trap, where evidence sits on an admin's local machine until they leave the company. If the evidence isn't centralised and indexed by the relevant ISO 27001 clause, it effectively doesn't exist when the external auditor arrives.

• The Control ID: Linked directly to your Risk Treatment Plan or Annex A.
• The Population: The total number of instances (e.g., all 50 laptops in the fleet).
• The Sample Size: How many you actually checked (e.g., 5 laptops).
• The Evidence Reference: A unique link to the specific log, ticket, or screenshot.
• The Result: A clear Pass/Fail with a date and signature.

Operationalising Compliance Without the Friction

Operational teams hate GRC because it’s usually an interruption. To win them over, you must integrate testing into their existing workflows. If they live in Jira, your control tests should be Jira tickets. If they live in GitHub, your evidence should be in pull request comments. The goal is 'invisible compliance'—where the very act of doing the work generates the evidence needed for the audit. This reduces the friction of Clause 7.5 (Documented Information) significantly.

Finally, always link your testing results back to your sales velocity. When a prospect sends over a 200-question security questionnaire, having a pre-tested, evidence-backed control library turns a three-day headache into a thirty-minute export. Control testing isn't just a regulatory burden; it's a competitive advantage that proves you are a 'Big Boy' company ready for enterprise contracts. Treat it as a sales enablement tool, and you'll find the budget and willpower to do it right.

Frequently asked questions