The Compliance Directive: One Sentence About a Security Standard Turns "Working" LLM Code Into Secure Code

STEP 1 (no method): Prompt about the task with no mention of security
→ model writes working code with a partial set of protections
(only the ones "baked into" the standard way of writing this kind of code)

STEP 2 (the method): Add one sentence to the same prompt:
"this data is sensitive, the artifact must comply with [standard]"
→ model fills in the full set of technical measures on its own (encryption,
access control, logging, retention)

Everything happens in a single prompt — no separate follow-up requests needed.

Task: The owner of a small online service asks Claude to write backend code for a lead-capture form that collects customers' email and phone number to store in a database for email marketing.

Prompt:

Write Python (Flask) code for an endpoint that accepts an email
and phone number from a website form and saves them to a PostgreSQL database.

This is customer personal data, so processing must comply
with GDPR/CCPA requirements and include encryption at rest, restricted
access to the database, access logging, and a data retention policy.

Result: The model writes code that encrypts fields on write to the DB, avoids hardcoding database passwords (using environment variables instead), logs every access to the data, and includes a sample policy for purging stale records. Without that second paragraph about GDPR/CCPA, the model would most likely have produced a plain, working INSERT with none of these protections — the code would "work," but it would be riddled with holes.

By default, the model solves literally the task it was given. If the task is "save this email to the database," it does exactly that, with the minimal set of actions required. Extra steps — encryption, logs, retention — aren't part of the task definition, so the model doesn't add them, even if it technically knows how.

At the same time, the model absolutely knows which specific measures correspond to standards like SOC 2, GDPR, or CCPA — that's a massive slice of information it absorbed during training. The problem isn't lack of knowledge; it's that without an explicit trigger, the model doesn't treat that knowledge as part of the request.

By naming the standard, you change the actual framing of the task — "write the code" becomes "write code that complies with standard X," and the model pulls out the entire mental checklist of technical measures it associates with that standard.

Levers you can pull: - Swap "SOC 2" for GDPR, PCI DSS, CCPA, HIPAA — the model will apply exactly the set of measures it associates with the named standard. - Specify the data type ("personal data," "payment information," "health data") — this is a second trigger that amplifies the effect. - For narrow, specific measures (MFA, cookie flags, account lifecycle policies), the generic phrase doesn't cut it — you need to name those separately and explicitly.

Write {code/function/service} for {task}.

This data is {data type: personal data / payment information /
health data}, and processing must comply with {standard:
SOC 2 / GDPR / CCPA / PCI DSS} and include encryption at rest,
restricted access, access logging, and a data retention policy.

Fill in {task} with a concrete description of what the code should do, and {standard} with the law or standard actually relevant to your situation (for US-based projects, that's often CCPA, HIPAA, or PCI DSS depending on the data type).

⚠️ The directive doesn't cover everything: MFA, Secure/HttpOnly cookie flags, account lifecycle rules — the generic standard-mention phrase doesn't activate these. You need to name them separately, by name.

⚠️ 100% on the checklist is not a guarantee of passing a real audit. Compliance was measured against the researchers' own technical interpretation, not an official SOC 2 checklist — the standard dictates goals, not specific technical implementations.

⚠️ Model choice barely matters. The difference between Claude Fable 5, Opus 4.8, and Opus 5 was minimal — the effect comes from how the prompt is worded, not from which specific model you pick.

⚠️ Eyeballing the code or running a pattern-based automated scanner isn't reliable. These scanners produce both false alarms and missed real holes — you need a review based on actual meaning (e.g., having another model or a human read the whole thing).

A team from Vanta took three top-tier Claude models and asked them to write code for four typical tasks: uploading files to S3, an authentication service, database infrastructure in Terraform, and a file-upload handler for personal data. Each task was run twice — once with a neutral prompt (zero mention of security) and once with the same prompt plus one sentence about SOC 2. Results were checked against a pre-written checklist of 12–15 items, each tied to a specific standard requirement, and every failure was manually verified rather than trusted to automation.

A fun detail: the first version of the "dangerous actions" checklist found zero problems across 16 generations — and that wasn't a flaw in the code, it was a flaw in the checklist. When the researchers expanded the list of vulnerabilities to check for, real defects surfaced: an exposed debugger with remote code execution, an unauthorized endpoint leaking other users' data. This directly confirms the main practical takeaway: automated pattern-matching scanners regularly get it wrong in both directions, and blindly trusting them to review AI-generated code is a bad idea.

Can AI Write Compliant Code, and to What Extent? — Iccha Sethi, Herman Errico (Vanta).