security-compliance-check

Security and compliance check

The pre-release pass on data handling.

Why this exists

Security review in a large organization has a lead time — often weeks — and it happens at the end. That produces two bad outcomes: a change blocked days before release by something that could have been designed differently, or a change that passes because the reviewer had twenty minutes and no context.

This skill is the pass you do, early and with full context, so the formal review finds nothing surprising. It doesn't replace the organization's review. It makes it fast.

There's a narrower reason too. The most common data-handling defects are not sophisticated attacks — they're a field added to a log line, a payload cached somewhere new, a token in an error message. They're introduced casually, they pass code review because they look harmless, and they're found in an audit a year later.

When this applies

• Pre-release, on anything touching personal, payment, or health data
• Anything touching money, authentication, authorization, or an audit trail
• A change adds a new data field, a new external call, or a new storage location
• Anything already inside a regulatory scope — SOX, PCI, HIPAA, GDPR

When it doesn't

• Changes that touch no data and no external surface
• Internal tooling with no sensitive data
• This is not a penetration test or a threat model, and shouldn't be presented as one

Prerequisites

• .fde/03b-nfrs.md — the data classification and audit obligations
• .fde/06-blast-radius-*.md — where data flows
• .fde/06b-change-log.md — what actually changed

Know the organization's own review process and its lead time before starting. See change-control-navigation.

First action, not last: file the formal review (or /security-review plus this pack) as soon as you know the data classification. The rest of this skill is so that review finds nothing surprising. Starting it at go-live is the failure the why-section describes.

Procedure