Certification and Architecture

Definition

Certifications assert that an organisation operates a defined set of controls. Their architectural impact runs through three mechanisms: scope, evidence and boundaries.

Scope is the decision that matters

Everything in scope must be controlled, evidenced and audited, annually, forever. So scope is the largest architectural lever available, and reducing it is worth more than any control applied to a wider surface.

Concretely: if the regulated data can be confined to a small, well-defined subsystem — or kept out entirely by tokenising at the edge — the audit surface reduces by an order of magnitude.

The corollary: the scope boundary must be a technical boundary, not a documentary one. A scope that does not correspond to an account, a network or a cluster cannot be demonstrated convincingly and will be challenged.

Evidence must be automatic

Auditors need proof that a control operated throughout the period, not that it exists today.

If evidence is gathered by screenshots and spreadsheets, certification consumes engineering time every year forever. If access reviews, change approvals, vulnerability scans, backup tests and deletion jobs emit structured evidence as a side effect of normal operation, the audit is an export.

This is the difference between certification as an annual project and certification as a property of the platform, and it is decided by architecture rather than by process.

The controls that become architectural requirements

• Access control with periodic review, which requires knowing who has access to what — harder than it sounds in a large estate.
• Change management with evidence — increasingly satisfied by an automated pipeline that records approvals, tests and deployments, which is a better outcome than a board.
• Logging and monitoring with retention, tamper-evident.
• Encryption in transit and at rest, with key management.
• Backup and tested restore, with the test evidenced.
• Asset inventory, which is a prerequisite for almost everything else.

Failure scenarios

• Scope undefined, so everything is in it.
• A scope boundary that is documentary rather than technical.
• Manual evidence, consuming a quarter of engineering time annually.
• Controls in each team rather than in the platform, so each is separately audited and separately fails.
• Certification treated as security. They overlap and are not the same thing.

Interview question

"How does pursuing a certification change how you design, beyond adding controls?"