From security tools to an auditable control system

Most organisations are not starting from zero

Most organisations already operate a substantial set of security safeguards. Vulnerability scanners identify weaknesses, web application firewalls filter application traffic, network firewalls restrict connections, identity and access management controls limit access, endpoint tooling protects devices, backups support recovery, and asset inventories record at least part of the estate.

Operational processes also exist for joiners, movers and leavers, patching, software delivery, access reviews, incident handling and change management. This work provides a useful implementation baseline, but it does not establish compliance by itself. A compliance conclusion requires defined criteria, confirmed scope, tested coverage and evidence that the controls operate as described.

Technical controls are widely deployed, but less often formalised

Eurostat's 2024 survey found that 92.76% of EU enterprises with at least 10 people used one or more ICT security measures. Strong password authentication was reported by 83.69%, separate-location or cloud backups by 79.23%, and network access controls by 65.43%.

Only 35.50% reported documents that put ICT security measures, practices or procedures in place, and 21.82% had defined or reviewed those documents during the previous 12 months. Bulgaria reported documentation at 13.67%. The figures do not measure compliance with a specific framework, but they show a clear gap between deploying safeguards and managing them as documented controls.

The UK Cyber Security Breaches Survey 2025/2026 shows a similar operating pattern outside the EU. Among businesses, 81% used current malware protection, 74% used secure cloud backups, password policies and network firewalls, and 73% restricted administrative rights. Only 30% had conducted a cyber security risk assessment and 25% had a formal incident response plan.

A deployed product is not a complete control

A scanner licence does not show that every relevant asset is scanned, findings reach an accountable owner, remediation follows an approved deadline, exceptions expire, or fixes are verified. A firewall rule base does not show that business ownership is current, changes are approved, obsolete rules are removed, and review results are retained. An identity platform does not prove that every worker is covered by the joiner, mover and leaver process or that privileged access is reviewed on time.

A usable control definition connects the security objective to its scope, owner, operating procedure, frequency, expected evidence, health measures, exceptions and response to failure. Without those elements, teams depend on individual knowledge and cannot demonstrate consistent operation across a reporting period.

Make the control repeatable

Replace statements such as "the team patches systems regularly" with an operating rule that another qualified person can follow. Define the in-scope asset population, how vulnerabilities enter the queue, remediation targets by severity, approval requirements for exceptions, escalation thresholds, rescan requirements and the records retained after closure.

The same structure applies to access reviews, firewall changes, backups and secure development. Each process needs a trigger or frequency, named roles, inputs, decision points, required outputs and a failure path. A control that works only when one employee remembers an undocumented step is not repeatable.

Make the control measurable

Metrics should show coverage, timeliness, failure and recovery. For vulnerability management, useful measures include asset coverage, scan success, remediation time by severity, overdue exceptions and successful rescans. For joiner, mover and leaver controls, measure personnel-event coverage, provisioning and deprovisioning time, review completion, unresolved entitlements and failed integrations.

A metric needs an owner, data source, calculation rule, reporting frequency, threshold and response. Counting scanner findings without asset coverage or remediation age produces activity data, not control health. Select measures that can trigger an operational decision.

Make the control modular

Define each control once in a vendor-neutral control library, then map applicable requirements from ISO/IEC 27001, NIS2, DORA, PCI DSS, customer contracts or internal policy to that control. This avoids separate procedures for requirements that depend on the same technical mechanism and gives control owners one operating model to maintain.

Mapping does not make standards interchangeable. Scope, wording, evidence expectations, reporting duties and legal effect still need separate analysis. Reuse the control and its evidence only where the underlying requirement and population genuinely overlap.

Design evidence into the operation

Evidence should be produced by the control during normal operation. Useful records include scanner exports, ticket timestamps, firewall and web application firewall policy history, identity events, approvals, access-review decisions, restore-test results, exceptions and closure records. Define the authoritative source, collection method, retention period, access restrictions and review responsibility before the assessment begins.

A screenshot usually proves a configuration at one moment. It rarely proves population coverage, continuous operation or timely exception handling. Evidence must support the specific claim being tested and preserve enough context to reproduce the conclusion.

Do not assign a compliance percentage yet

An organisation with established tools and operating routines is further ahead than a greenfield programme, but a claim such as "90% compliant" is not defensible until the target standard, legal entity, services, systems, locations and reporting period are defined. The control mapping then needs to test applicability, implementation, operating evidence, exceptions and any framework-specific requirements.

Start by inventorying the controls already in operation and recording design, implementation, operation, evidence and effectiveness as separate states. Select one business service or compliance objective, confirm the applicable requirements, map them to the existing controls, and create a remediation backlog for unsupported claims and uncovered requirements. The next article will cover choosing the target standard and building a control matrix without duplicating the operating model.