SOC 2, GDPR and HIPAA: What to Build In From Day One

Which compliance requirements for custom software actually reach the code

Most of what gets called compliance is paperwork: policies, registers, vendor reviews, signed agreements. The compliance requirements for custom software are the smaller subset the code itself has to satisfy, and they behave differently. A policy can be written in a fortnight. An audit trail that does not exist cannot be produced retrospectively, and a deletion capability that was never designed cannot be added without touching every table.

That asymmetry is the whole argument for reading this before the architecture is fixed. The engineering obligations under GDPR, SOC 2 and HIPAA overlap heavily — identity, access control, logging, encryption, retention, deletion — and building them once, early, costs a fraction of retrofitting any one under audit pressure.

None of these regimes tells you how to build anything. GDPR names pseudonymisation and encryption as examples and otherwise asks for security appropriate to the risk. The SOC 2 criteria describe outcomes. The HIPAA Security Rule splits its specifications into required and addressable, where addressable means implement it or document why it is not reasonable and implement an equivalent. Auditors assess judgement, which has to be written down at the time.

Which regime applies, what the code must do, and what it costs to retrofit

The triggers above are simplified deliberately. Treat the table as a map of engineering consequences, and have scope confirmed by someone qualified.

What GDPR requires of the code itself

Strip away the documentation and GDPR leaves a set of concrete properties the system must have. Each is a schema decision more than a feature.

• A lawful basis attached to each processing purpose, and a way to demonstrate it. Where the basis is consent, the record needs the notice version, timestamp and mechanism. A boolean column called marketing_opt_in is not a consent record.
• Data minimisation as an active constraint. Every signup field should have a stated purpose; date of birth collected in case it proves useful is the textbook failure.
• Access and portability exports produced on demand. Article 12 allows one month, extendable by two further months for complex requests; hand-assembling an export from six services does not survive real volume.
• Storage limitation implemented in code — a scheduled job that deletes or anonymises records past their retention period, not a document describing what someone should do.
• Data residency you can actually control. Committing to EU-only storage means auditing where every managed service, error tracker and AI API sends payloads, and where its subprocessors sit.
• Detection and escalation fast enough to notify a supervisory authority within 72 hours of becoming aware of a breach — a monitoring and on-call requirement dressed as a legal one.

Article 25 asks for data protection by design and by default, the clause that most directly governs architecture. In practice: the private setting is the default, the smallest useful dataset is the one collected, and the choice not to encrypt a field was recorded as a decision.

Why the right to erasure breaks soft deletes and backups

Erasure is where most applications discover their data model is not compliant, because almost every codebase soft-deletes. A deleted_at timestamp keeps referential integrity intact and makes undo trivial — and it leaves the personal data sitting in a table, readable by anyone with database access. A soft delete satisfies a product requirement, not an erasure request.

A hard delete is often impossible: order history has statutory retention, financial records must be kept for tax, aggregate metrics must not silently change. The workable pattern is crypto-shredding with anonymisation — encrypt each subject's personal fields under a per-subject key, then on erasure destroy the key and overwrite the direct identifiers. The order rows survive with their amounts and dates; the person behind them does not.

Then there are the copies. Personal data is rarely only in the primary database. It is in read replicas, the search index, the cache, the warehouse, queue retention, application logs, the error tracker's captured request bodies, the email provider and nightly backups. An erasure implementation that touches only the primary store is not one.

Backups are the hard case, since rewriting an immutable backup is neither easy nor desirable. The position most organisations document is that backups are held for a defined short period, encrypted and access-controlled, and any restore replays the outstanding erasure log first. That append-only log of already-erased subjects has to be built; it cannot be reconstructed later.

What SOC 2 actually audits — your process, not your code

SOC 2 is the one most often misunderstood, and understanding it correctly saves wasted engineering. It is not a certification and there is no compliant-product badge. It is an attestation report from a licensed CPA firm saying the controls you described were suitably designed and — in a Type II report — operated effectively across an observation period, commonly three to twelve months.

Nobody inspects your source code. What gets tested is whether the controls you wrote down were followed, with evidence, on the dates sampled. The engineering consequence is direct: controls must produce their evidence automatically, because a control whose evidence is somebody's memory fails on sampling.

The Security criteria are common to every engagement; Availability, Processing Integrity, Confidentiality and Privacy are added according to what you commit to. In build terms the recurring work is unique named identities with no shared logins, server-side role-based access control, joiner-mover-leaver provisioning that actually revokes, branch protection so every production change is reviewed and traceable, encryption in transit and at rest, centralised logs with alerting, tested restores and periodic access reviews.

The timing consequence is what catches teams out. Because Type II tests operation over a period, controls introduced in March generate no evidence for January. If a buyer wants a report in six months, the controls need to be running now — the strongest practical argument for building SSO, audit logs and review-gated deploys into the first release rather than the tenth.

What HIPAA requires that your cloud provider's compliance does not cover

AWS, Google Cloud and Microsoft Azure will all sign a business associate agreement and publish which of their services are eligible to handle protected health information under it. That is necessary, and routinely mistaken for sufficient. The provider secures the infrastructure. Whether your application enforces minimum-necessary access, logs every read of a patient record and terminates idle sessions is entirely yours.

The Security Rule's technical safeguards translate into specific application behaviour. Unique user identification is required, which rules out shared clinical accounts however convenient the ward finds them. Audit controls are required: mechanisms that record and examine activity in systems containing PHI, which means logging reads and not only writes, because inappropriate access to a record is the classic HIPAA incident. Automatic logoff and encryption are addressable — implement them or document a reasoned alternative.

Two obligations propagate outward. Every vendor that stores or processes PHI on your behalf needs a signed BAA: the database host, the log aggregator, the error tracker, the email provider, the AI API. If a service will not sign one, PHI must never reach it — a routing and redaction problem in your code. And breach notification runs to a clock: affected individuals no later than 60 days from discovery, with reporting to HHS within 60 days for breaches affecting 500 or more people and annually for smaller ones.

The pattern that keeps this tractable is treating PHI as a separate class of data with its own storage boundary, access path and logging, rather than as ordinary columns that happen to be sensitive. Systems that mix PHI through every table apply the strictest control everywhere, which is expensive, or apply it inconsistently, which is worse.

Which architectural decisions are cheap now and expensive later?

Four decisions account for most of the difference between a system brought into compliance in weeks and one that needs a rebuild. All four are days of work before launch.

Append-only audit logging, from the first commit

Every regime wants to know who did what, to which record, when, and from where. Write it as an append-only stream the application cannot update or delete, separate from debug logs, with reads recorded as well as writes. Retrofitting means finding every data access path in a mature codebase — the most expensive compliance project a team can take on.

// One append-only row per access. No update path, no delete path.
// Written from the data layer so no feature can bypass it.
interface AuditEvent {
  id: string;              // ULID: sortable, no collisions across nodes
  occurredAt: string;      // ISO 8601, UTC, from the server clock
  actorId: string;         // real user, never a shared service account
  actorIp: string;
  action: "read" | "create" | "update" | "delete" | "export";
  resourceType: string;    // "patient_record", "invoice"
  resourceId: string;
  tenantId: string;        // present on every row, always
  lawfulBasis?: string;    // GDPR: why this processing was permitted
  changed?: Record<string, { from: unknown; to: unknown }>;
}

Tenant isolation enforced below the query

Isolation must be structural rather than a WHERE clause each developer remembers. Postgres row-level security tied to a session variable, or a repository layer that refuses to build a query without a tenant scope, means a forgotten filter fails closed. A cross-tenant leak is a reportable breach in every regime here, and it is nearly always one missing predicate.

Field-level encryption for the fields that matter

Full-disk encryption protects against a stolen drive and nothing else; an application-layer compromise reads everything. Encrypting specific fields with keys held in a managed KMS, one per tenant or per subject, narrows the blast radius and makes crypto-shredding possible. It costs exact-match indexing on those fields, which is why the decision belongs at design time.

Deletion cascades and a maintained data map

Keep a written map of every place a personal identifier can come to rest, and an erasure routine that walks it. Update it as part of the definition of done for any feature touching personal data.

How compliance requirements for custom software change the way you scope a build

The practical move is to establish which regimes apply before the schema is written, not before the launch date. That answer determines the data model, the tenancy strategy, the logging design and the hosting region, all four cheap to choose and expensive to change. It also shortens scope, because the fastest way to reduce compliance obligations is to hold less data: card details that never enter your systems, personal fields never collected.

The second move is to make the evidence automatic. Controls that depend on someone remembering fail under sampling, and they fail during incidents. Controls implemented as pipeline gates, infrastructure policy and append-only logs produce their own evidence, turning an audit into a document-gathering exercise rather than a quarter of engineering.

If you are scoping a build with GDPR, SOC 2 or HIPAA in view, or discovering mid-flight that an enterprise buyer has just made one of them urgent, ApexStack works through these decisions with engineering teams before they harden.