Regulation and compliance fundamentals

A regulation is law — GDPR, HIPAA, SOX — enforced by a state authority with the power to fine you. A standard is a published specification you can be certified against, such as ISO 27001 or PCI DSS, and its force is contractual: a customer or a card scheme requires it, not a legislature. A framework is a structured set of control objectives you map yourself onto, such as NIST CSF or COBIT, with no certificate at the end. A policy is your own organisation's rule, written internally, and the only one of the four you can change unilaterally. The distinction decides who you can negotiate with. A policy can be amended by an internal decision, a standard is a commercial conversation, and a regulation is a constraint you design around — so establishing which one you are facing is the first useful question when told something is not allowed.

Because auditors test controls against objectives and rarely prescribe implementations. "The auditor requires ninety-day password rotation" is almost always somebody's summary of an objective about credential compromise, which your organisation chose to satisfy by rotation some years ago. That matters because the objective usually admits a better implementation — phishing-resistant multi-factor authentication, short-lived credentials issued per session — and you can only propose one if you can name the objective the existing control serves. The habit worth building is to ask which control a request maps to and which objective that control satisfies. When nobody can answer, you are complying with a policy that has outlived its reason, and changing it is paperwork rather than an argument with a regulator.

Compliance work is this trace repeated a few hundred times, and an engineer who can produce one row of it unprompted is immediately credible.

objective                      control                          evidence accepted
-----------------------------  -------------------------------  ------------------------------------
Only authorised changes        Every production change has a    Change record with PR link,
reach production               reviewed merge request and a     approver identity, timestamp, and
                               named approver who is not the    the pipeline run that deployed it
                               author

Access is removed when         Leaver process revokes all       Ticket from HR, dated access
someone leaves                 accounts within 24 hours         removal log per system, quarterly
                                                                reconciliation of active accounts
                                                                against the HR roster

Cardholder data is not         PAN is tokenised at the edge     Data-flow diagram, a scan of the
retained by the application    and never persisted by us        application datastore showing no
                                                                PAN, plus the vault's attestation

Backups can actually be        Quarterly restore test into an   Test record with date, operator,
restored                       isolated environment             restored dataset, measured RTO,
                                                                and the defects raised

Read the third column first, because it is the one engineers underestimate. An auditor is not testing whether your intent is good; they are testing whether an independent person can verify the control operated throughout the period. A control that works perfectly and leaves no artefact fails the audit, and that is not pedantry — an unevidenced control is indistinguishable from one nobody ran.

The second thing the table shows is that evidence is generated, not gathered. Every row above is a by-product of a system doing its job: the pipeline already knows who approved the merge, the identity provider already knows when the account was disabled. The expensive version is the one where a human assembles screenshots at the end of each quarter, because that scales linearly with scope and breaks the first time somebody is on holiday.

Third, notice that two rows include a reconciliation rather than only a log. A log tells you what your process did; a reconciliation tells you whether reality matches, and it is the only thing that catches the account created outside your process. Auditors ask for it because it detects the control being bypassed rather than failing.

The design consequence is to treat evidence as a functional requirement. When building the release pipeline, the access system, or the deletion job, ask what artefact it emits, where that artefact is retained, and for how long — because retrofitting it later means reconstructing a period you no longer have data for.

Compliance is meeting a defined set of controls that somebody else wrote, assessed at a point in time against a scope you agreed. Security is the actual property of being difficult to attack. They overlap substantially and neither implies the other. A system can pass every PCI requirement and be trivially exploitable through a business-logic flaw nobody wrote a control for, and a genuinely secure system can fail an audit because it cannot produce records. The useful framing in an interview is that compliance sets a floor and defines the language you use to argue for security spending, while the threat model is what tells you where the real risk is. Treating the audit report as a security assessment is the mistake that produces breached, certified companies.

The register is where compliance and engineering actually meet, because the residual column is a decision somebody has to sign.

Risk ID                 R-114
Risk                    Customer PII exposed through an over-permissive
                        object-storage bucket
Owner                   Head of Platform
Inherent likelihood     4 of 5      (misconfiguration is common and easy)
Inherent impact         5 of 5      (regulatory notification plus contract breach)
Inherent rating         20          HIGH

Controls                1. Buckets default to private, enforced by policy-as-code
                        2. CI fails on any public-access grant
                        3. Daily scan of live configuration with alert
Control effectiveness   Assessed EFFECTIVE, tested 2026-05-12

Residual likelihood     2 of 5      (requires bypassing CI and the daily scan)
Residual impact         5 of 5      (unchanged - impact is rarely reduced by
                                     preventive controls)
Residual rating         10          MEDIUM
Treatment               ACCEPT, reviewed quarterly
Accepted by             CTO, 2026-05-20

The single most instructive line is that impact did not move. Preventive controls reduce likelihood; only a change to the data itself — holding less of it, holding it tokenised, shortening its retention — reduces impact. Candidates routinely claim a control lowered both, which tells an experienced interviewer that the model is being filled in rather than reasoned about.

The second point is that residual risk is accepted by a named person, not by the engineering team and not by the register. This is the mechanism by which an organisation converts a technical fact into an owned business decision, and it is why raising a risk formally is more effective than raising it in a stand-up. If the answer is "accept", you have documentation; if the answer is "that is unacceptable", you have funding.

Third, the treatment options are a fixed vocabulary — mitigate, transfer, accept, avoid — and knowing them keeps a conversation productive. Insurance is transfer. Removing the feature is avoid. Most engineering work is mitigate, and most arguments happen because someone wants mitigate and someone else has quietly chosen accept.

The engineering reading is that a risk register is a prioritisation tool you can use. A finding with a residual rating and a review date beats an architectural concern raised in a document nobody signed.

It is the recognition that your compliance obligations do not stop at your perimeter: if a sub-processor loses your customers' data, you are the one who notifies the regulator. Practically this means every vendor holding regulated data needs a due-diligence record, a contract with data-protection terms, an identifiable location for the data, and a place in your register of sub-processors. The engineering consequences are concrete — you cannot adopt a new analytics SDK unilaterally, an integration must log what it sends, and any vendor in a critical path needs a documented exit plan, because concentration on a supplier you cannot leave is itself a finding in regulated sectors.