Governance engineering

Governance starts with what teams already do every day. Built on those activities, it gives non-technical stakeholders something they understand and auditors something they accept, with only the overhead that adds value. Here is how that applies to DORA, PCI DSS and the CRA.

Book a call Connect on LinkedIn

Principles

Start from daily work
Standups, code reviews, vulnerability scans, deployments. These already happen every day, and teams already care about them. A control framework built on them is one teams follow without working around it.
Monitor compliance like security
Compliance validates that you did the right thing, and most of the right thing is security. Security teams already monitor continuously: alerts, dashboards, someone who responds. Extend that monitoring to cover the compliance requirements, and every case is checked as it happens, instead of a sample at audit time. More in a thousand audits a day and the talk on auditing at scale.
Evidence as a byproduct
Automate a control once and maintain it like code, and the evidence is already there when the audit comes. Automation needs owners and maintenance, so start where manual effort or audit risk is highest.
Spend where it matters
Every framework leaves room for judgment. Experience shows where the effort actually needs to go, and where the standard allows you to spend less.

DORA

DORA is usually run as a documentation exercise. Most of it works better as an engineering and data problem: metrics you can monitor, processes you rehearse, and registers fed by the systems that already hold the data.

	Usually	Engineering first
ICT risk management	A risk register that goes stale between reviews.	Each risk tied to metrics the platform already produces, monitored continuously and reviewed with numbers, not opinions.
Incident reporting	A procedure that runs for the first time during the first major incident.	Classification criteria encoded, the right people pulled in automatically, and the process rehearsed.
Resilience testing	A failover plan nobody has run: an assumption, not a control.	Failure modes mapped for the product and the process around it, and tested against on a schedule.
Third-party oversight	A spreadsheet completed by hand before each submission.	A Register of Information connected to the systems that already track vendors, like procurement and invoicing, and validated before every submission.
Information sharing	A separate exchange, kept apart from the security team’s daily work.	Threat and incident signal exchanged through channels the security team already uses, and fed back into detection.

More on the Register of Information: why it is a data problem, why it can look complete and still fail validation, and what breaks after the first submission.

PCI DSS

PCI DSS's structure already reads close to how engineering teams think. What experience adds is judgment: where the effort actually needs to go, and where the standard leaves room to spend less.

Tokenise on entry

Scope

Minimise scope

The smaller the environment that touches real card data, the smaller the attack surface and the audit both. Tokenizing on entry is one way: operate on the token everywhere else, and reconstruct the real number only where it must reach an acquirer or another PSP.

Cloud key management

Inherit

Outsource what makes sense

Some requirements are cheaper to inherit than to build. Encryption key management is a good candidate: a cloud provider’s key management service can carry most of PCI DSS’s key management requirements on its own attestation, already assessed, already documented.

Firewall rules diffed against the approved baseline

Evidence

Automate the evidence, not just the control

Evidence that’s a side effect of the work itself carries more weight than evidence assembled specially for the auditor. A scheduled diff of firewall rules against the last approved baseline, flagging drift automatically, is one example: the record already exists when the assessment comes around.

Metrics on approvals and tickets

SDLC

Stay close to the SDLC

Problems are cheaper to fix the moment they happen than the week before an audit. Metrics on the SDLC itself, approvals completed, tickets documented, can surface deviations in real time.

CRA

CRA's essential requirements (Annex I) are organised the way law is written: a list of clauses. Organised the way engineering is done, they cluster into six themes, and most map to things a mature SDLC already produces.

Theme	Annex I asks for	Evidence comes from
Secure by design and default	Secure defaults, a minimal attack surface, access control.	Architecture review, and checks that enforce it in the pipeline, not a document written after release.
Data and resilience	Confidentiality, integrity, data minimisation, and availability under stress, including denial of service.	Good architecture covers most of it; tests and design records prove it.
Visibility and control	Logging, monitoring, reporting unauthorised access, and letting users remove their data securely.	Product features with acceptance criteria, built and tested like any other.
Vulnerability management	A software bill of materials, vulnerability handling and coordinated disclosure.	An SBOM generated by the build, scanning on every change, remediation tracked against deadlines, and a published disclosure policy.
Keeping it updated	Secure, timely updates, with users notified and able to postpone.	The release pipeline. If it already does this, the pipeline is the evidence.
Good neighbour	Limits on the product’s impact, and that of connected devices, on other services.	Design decisions, made and recorded in architecture review.

Working on DORA, PCI DSS or CRA?

Book a call to talk it through, or connect on LinkedIn.