ComplianceOps

WHAT IT IS. Compliance operations is the practice of producing control evidence as a by-product of normal engineering, continuously, instead of reconstructing it under deadline. A control states an intent ("access is reviewed quarterly"); compliance operations makes the system emit proof that the intent held, on a schedule, without a human assembling screenshots. WHY IT EXISTS. The default mode is the audit sprint: weeks of engineers hunting for artefacts that describe what happened months ago, producing evidence that is accurate, expensive and instantly stale. It also produces a subtler harm — teams learn that compliance is theatre, and stop believing controls mean anything. This area exists to make the evidence continuous and therefore cheap, and to make the control itself honest. WHEN TO USE IT. When a framework becomes a business requirement — a customer questionnaire, a certification, a regulator — or earlier if you already know it is coming. Doing it early is dramatically cheaper: retrofitting evidence onto systems that never emitted it is where the cost lives. Note that this is operations, not legal interpretation; scope and applicability decisions belong with /grcops. WHO OWNS IT. A compliance function owns the mapping from framework to control and the evidence calendar; engineering owns the systems that emit evidence; each control has one named owner who can explain it without reading the policy. Auditors are consumers, not owners, and designing for the auditor's convenience at the expense of the control's usefulness is the classic failure. WHAT GOOD LOOKS LIKE. Every control maps to an automated evidence source with an owner and a cadence, and the gap between "control passed" and "we can show it passed" is zero. Evidence is generated by the system of record — the ticket, the pipeline, the access log — not screenshotted from it. Control failures raise the same kind of ticket as a production defect, with a due date. Nobody is surprised by an audit finding, because the dashboard showed the drift weeks earlier. Crucially, controls that no longer make sense get retired rather than quietly faked. HOW TO IMPLEMENT. Start with the control list you are actually assessed against and delete the aspirational extras. For each, write down what would convince a sceptical outsider, then find the system that already knows it. Automate the three most frequently sampled controls first — usually access review, change management and backup restoration — because they consume the most manual effort. Put evidence generation on a schedule with an alert when it fails, exactly as you would a backup job; see /runbooks for the restoration proof and /assess to score your current posture. Keep a register of control exceptions with expiry dates. HOW TO ASSESS YOURSELF. If an auditor asked today for evidence that access was reviewed last quarter, how long would it take, and who would do the work? What percentage of your controls produce evidence automatically? When a control last failed, did anything alert, or did you find out at audit? Score at /assess and run the readiness pass in /checklists.