Security & Compliance Quick-Ref (FDE)

Enough to earn a security team’s "yes": what SOC 2 / HIPAA / GDPR actually ask, how to handle data and secrets, and what reviews check.

Compliance frameworks are mostly the same handful of controls in different vocabularies: know what data you hold, encrypt it, restrict and log who can reach it, keep only what you need, manage the vendors who touch it, and have a plan for when something goes wrong. A security team’s job is to verify those controls exist, so the fastest route to their yes is arriving with the evidence: a data-flow diagram, the access model and completed questionnaires.

This is an engineer’s orientation, not legal advice; the customer’s security, privacy and legal teams have the final word.

The frameworks (what they care about)

SOC 2: Trust controls: access control, encryption, change mgmt, monitoring, vendor risk. Report, not a law.
SOC 2 Type I vs II: Type I: controls designed well at one point in time · Type II: shown working over 3–12 months
ISO 27001: certifiable international standard for an information security management system
HIPAA: US health data (PHI). Needs a BAA, encryption, access logs, minimum-necessary access.
BAA: Business Associate Agreement — required before any vendor, an LLM API included, touches PHI
GDPR: EU personal data. Lawful basis, data-subject rights (access/delete), data-residency, DPA.
CCPA / CPRA: California privacy law: rights to know, delete and opt out of the sale or sharing of data
PCI-DSS: Card data. Easiest win: never touch it — tokenize / use a processor.
FedRAMP: US federal authorization needed to sell cloud services to most agencies; slow and costly
EU AI Act: risk-tiered AI rules: some uses banned, duties for high-risk systems and general-purpose models

Data handling

Encrypt everywhere: TLS in transit; encryption at rest. Non-negotiable table stakes.
Data residency: Know which region/network data must stay in. Drives the deployment target.
Minimize + retain: Collect only what you need; delete on a schedule. Less data = less risk.
PII discipline: Redact/mask in logs and prompts. Never paste customer PII into a third-party API without approval.
Data classification: label data public, internal, confidential or regulated — every control keys off the label
Pseudonymization: swap identifiers for tokens; under GDPR it is still personal data while the mapping exists
Deletion that works: covers backups, logs, caches, search indexes and vector stores, not just the main table

Secrets & access

No secrets in code/repo: Use their vault/KMS + env injection. Rotate. Never log a token.
Least privilege: Scope keys to exactly what’s needed; short-lived over long-lived.
Audit trail: Log who did what, when. Immutable, exportable — reviewers will ask.
MFA + SSO: Integrate with their identity provider; don’t create a parallel login.
Service accounts: one per workload with a narrow role — never a person’s credentials in automation
Secret scanning: scan repos and CI logs for leaked keys, and rotate at once when one turns up
Break-glass access: emergency admin access that is logged, time-limited and reviewed afterwards

AI & LLM specifics

Provider data terms: confirm inputs are not used for training and how long they are kept — in the contract
Zero data retention: some providers offer ZDR for sensitive workloads; check which features it excludes
PII in prompts: redact or tokenize before sending; store prompt logs only in an approved, access-controlled place
Prompt injection: treat retrieved documents as untrusted input and limit which tools a model can call
Permission-aware RAG: filter retrieval by the user’s access rights at query time, not only at indexing
Residency for AI: regional endpoints or self-hosted models when data may not leave a jurisdiction

Logging & incidents

What to log: sign-ins, admin actions, data exports and permission changes: who, what, when
Never log: passwords, tokens, full card numbers, or prompts and payloads full of personal data
Log retention: keep audit logs as long as the framework or contract asks, protected from edits
Breach deadlines: GDPR: the regulator within 72 hours of awareness · HIPAA: individuals within 60 days
Incident runbook: who to call, how to contain, who decides on notification — written before you need it

Vendors & subprocessors

Subprocessor list: every third party that touches customer data; customers may object to changes
DPA: Data Processing Agreement: the contract GDPR requires between controller and processor
SCCs: Standard Contractual Clauses — the usual legal basis for moving EU data abroad
Vendor review: a security questionnaire, SOC 2 report and pen-test summary before onboarding

The security review

Bring the answers: Data flow diagram, where data lives, encryption, access model, subprocessors.
Smaller ask = faster yes: Request minimum scope + a bounded footprint; huge asks stall.
Involve them early: A veto at the end kills the deal. Loop security in during discovery.
Questionnaires: SIG, CAIQ or the customer’s own spreadsheet — keep a library of approved answers
Pen-test report: a recent third-party test summary answers many questions at once
Architecture diagram: data flows, trust boundaries and where encryption applies — reviewers start here
Exceptions in writing: when a control can’t be met, document the compensating control and get sign-off

Recipes

The one-page data-flow summary reviewers ask for

Data:           support tickets with names and emails (PII); no payment or health data
Flow:           customer helpdesk → our API (TLS 1.2+) → Postgres in eu-west-1 (encrypted at rest)
LLM use:        ticket text sent to the model provider under no-training, limited-retention terms
Access:         SSO + MFA; 4 engineers with production access; every query logged
Retention:      raw tickets 90 days, then deleted from the database, backups and the vector index
Subprocessors:  cloud host, model provider, error tracker (listed in the DPA)

Answering these six questions up front pre-empts most of a security questionnaire and shows the reviewer you already think the way they do.

Redact PII before it reaches a log or a prompt (Python)

import re

EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
CARD = re.compile(r"\b\d(?:[ -]?\d){12,15}\b")

def redact(text: str) -> str:
    text = EMAIL.sub("[email]", text)
    return CARD.sub("[card]", text)

Regexes catch only the obvious formats; for names, addresses and free text use a dedicated PII detector, and redact at the edge so raw data never lands in logs.

A least-privilege access request for an integration

Need:    read-only access to orders from the last 30 days
Grant:   a dedicated service account with role orders.read, scoped to one project
Avoid:   an admin's personal API key, wildcard scopes, keys that never expire
Rotate:  every 90 days, stored in the customer's vault, injected at runtime
Audit:   every call logged with the service account ID and reviewed monthly

A smaller ask gets approved faster and limits the damage if the credential leaks, which is exactly what the reviewer is weighing.

Handling a GDPR deletion request

1. Verify the requester's identity
2. Find every copy: database, replicas, backups, logs, caches, search and vector indexes, analytics
3. Delete or anonymize, and record what was removed and when
4. Tell your processors and subprocessors to do the same
5. Reply within one month (extendable when requests are complex)

The deadline runs from receipt, and the copies people forget, such as backups, exports and embeddings, are where audits find the gaps.

Questions about Security & Compliance Quick-Ref (FDE)

What is the difference between SOC 2 Type I and Type II?

Both are attestation reports from an independent auditor against the AICPA Trust Services Criteria, most often the security criteria. A Type I report says the described controls were suitably designed at a single point in time. A Type II report says the controls also operated effectively over an observation period, usually three to twelve months, based on sampled evidence. Enterprise buyers generally expect Type II, because it shows the controls actually work day to day. Startups often get a Type I first and follow it with a Type II after the first observation window.

Can I send customer data to an LLM API?

Only with the customer’s approval and under the right terms. Check the provider’s data-use policy, which should state that API inputs are not used for training, confirm how long prompts and outputs are retained, and sign a data processing agreement, plus a Business Associate Agreement for health data under HIPAA. Residency requirements may call for a regional endpoint or a self-hosted model. Send the minimum the task needs, redacting personal data where possible, and list the provider as a subprocessor in the customer’s documentation.

What does a security review of a vendor usually check?

Reviewers want to know what data you will touch and how it is protected. Expect questions about the data flow and where data is stored, encryption in transit and at rest, authentication and single sign-on, who in your company can access customer data and how that access is logged, how you manage secrets and vulnerabilities, your incident response process, your subprocessors, and certifications such as SOC 2 or ISO 27001. Arriving with a data-flow diagram, a pre-filled questionnaire and a narrow access request is the fastest way through.

How quickly must a data breach be reported under GDPR?

A controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. When the risk to individuals is high, they must also be told without undue delay, and processors must inform the controller without undue delay. Contracts often impose shorter deadlines, so the incident runbook should name who decides, who notifies and which customers must hear first.

Go deeper

Deployment targets →API security checklist →