Articles about compliance and risk from security operations practitioners.
The ISO 27001-to-SOC crosswalk takes an afternoon. The decision that actually costs you is whether audit evidence gets generated by your production systems as a byproduct, or reconstructed by an analyst every audit cycle. I build for the first, so the evidence is a record of operations, not a second job.
ISO 27001 mapping rarely begins with a missing SOC capability. The trigger is usually a customer request, a 93-control Annex A spreadsheet, and a harder question: can I prove what my SOC actually does? The answer lives in evidence, ownership, and an honest Statement of Applicability, not a SIEM screenshot.
Before last quarter's board prep, I re-cut our security operations budget against the six functions of NIST CSF 2.0. Detection tooling dominated the sheet; recovery had almost nothing against it, and governance wasn't even a line. Read as a checklist, the framework sends your budget in the wrong order.
I sat through a GRC platform renewal two weeks before a PCI assessment, watched the dashboard go green, and then watched the assessor ask for evidence that lived entirely in my SOC. Financial compliance isn't a project you buy. Most of the controls a financial-sector audit tests already run in the SOC, which just never gets credit for them.
I've run security operations at two companies with financial services compliance obligations. The regulatory frameworks were different, but the SOC's experience was consistent: we were the team that produced the evidence everyone else attested to, on timelines nobody had briefed us on before the audit.
The first security questionnaire is a research project; every one after that should be a lookup. Build a reusable evidence library once, route each section to its real owner, and stop answering the same encryption question from scratch every quarter.
Practitioner takes on SOC modernization, detection engineering, threat hunting, and more. No fluff. No product pitches.