Treating Compliance as an Engineering Problem

In many organizations, compliance is an annual emergency. Weeks before the audit, engineers stop shipping to collect screenshots, export access lists and update policies nobody has read since the last audit. Then the controls drift again until next year. Treating compliance as an engineering problem turns it into something that runs continuously, produces its own evidence, and makes the organization measurably more secure rather than just certified.

Know what you are signing up for

• ISO/IEC 27001:2022 is a certifiable standard for an information security management system. Its Annex A lists 93 controls grouped into four themes: organizational, people, physical and technological.
• SOC 2 is an attestation report based on the AICPA Trust Services Criteria. Security is always in scope; availability, processing integrity, confidentiality and privacy are optional. A Type II report covers how controls operated over a period, commonly between three and twelve months.
• PCI DSS v4.0 applies to anyone storing, processing or transmitting payment card data. Its future-dated requirements became mandatory on 31 March 2025.
• NIS2 widens the EU's cybersecurity obligations to many more sectors, makes management personally accountable, and sets incident reporting deadlines: an early warning within 24 hours, a notification within 72 hours and a final report within a month.
• DORA has applied to EU financial entities since 17 January 2025, covering ICT risk management, incident reporting, resilience testing and oversight of ICT third parties.
• Regional rules matter as much as international ones. In the Gulf, Saudi Arabia's NCA Essential Cybersecurity Controls and Personal Data Protection Law, and the UAE's Federal Decree-Law No. 45 of 2021 on personal data protection, frequently apply. In Lebanon, Law No. 81 of 2018 covers electronic transactions and personal data.

One control set, many frameworks

The frameworks overlap heavily. Implementing each one separately produces duplicate work and contradictory evidence. Instead, define a single internal control set in your own words, assign every control an owner, and map each one to the clauses it satisfies.

Controls as code

Many technical controls can be expressed as code and enforced automatically. Infrastructure-as-code changes are checked in the pipeline, cloud configuration is evaluated continuously with services such as AWS Config or Azure Policy, and Kubernetes admission policies block non-compliant workloads before they run. Each check that passes is evidence, generated without anyone taking a screenshot.

package compliance.storage

deny contains msg if {
  some r in input.resource_changes
  r.type == "aws_s3_bucket_public_access_block"
  r.change.after.block_public_acls == false
  msg := sprintf("%s must block public ACLs (ISO A.8.12, SOC 2 CC6.1)", [r.address])
}

Continuous monitoring and evidence

• Collect evidence on a schedule: access reviews, configuration snapshots, backup test results and vulnerability scan reports flow automatically into a central store with timestamps.
• Give each control owner a live view of their controls, and alert them when one starts failing instead of finding out during fieldwork.
• Treat control failures like production incidents, with a ticket, an owner and a due date.
• Keep audit readiness as a standing state. If an auditor arrived tomorrow, the evidence for the last twelve months should already exist.

The parts you cannot automate

Risk assessment, management review, vendor due diligence and security awareness still need people and judgment. Keep policies short enough that someone will read them, written for the way your organization actually works. Auditors increasingly test whether practice matches the document, and a beautiful policy describing a process nobody follows is a finding waiting to happen.

Common pitfalls

• Optimizing for the certificate instead of the risk. Passing an audit and being hard to breach are related, but they are not the same thing.
• Scoping too broadly at first. Start with the systems that hold the data the framework cares about, then expand.
• Buying a GRC platform before defining controls and owners. Tooling organizes a program; it cannot create one.
• Evidence by screenshot. It is slow, easy to fake, and proves only that something was true for one moment.

When controls run continuously and produce their own evidence, the audit becomes a review of data you already have. The time saved goes back into security work that actually reduces risk.