How to translate a regulation into engineering requirements

Legal precision and engineering precision are not the same skill. A rule can be written correctly by counsel and still arrive on an engineering backlog as a vague ticket, and the gap between those two forms of precision is where most real compliance failures start: the step where regulatory text becomes a system requirement, a step that usually has no clear owner.

This page is about financial regulation specifically: how to run that conversion for SEC, FINRA, and FTC requirements so the result is a requirement an engineer can build and an examiner can trace back to the rule.

Step one: split what reaches the code from what does not

Financial regulation covers a great deal that has nothing to do with your application. Governance, training, designated officers, board reporting, vendor diligence. Engineers do not need to read most of it, and giving them all of it to read guarantees they miss the parts that matter.

The useful split is between obligations satisfied by a person doing something and obligations that can only be satisfied by the system behaving a certain way. "Designate a qualified individual responsible for overseeing your information security program" [1] is a process obligation. Nothing in the code satisfies it. "Implement policies, procedures, and controls designed to monitor and log the activity of authorized users" [1] is a system obligation. No amount of process satisfies it if the application does not write the log line.

Do this split explicitly, in a document, with the sentence quoted next to each item. It takes an afternoon and it is the highest-value artefact in the whole exercise, because everything that follows traces back to it.

Step two: convert each system obligation into an assertion

A system obligation is not yet a requirement an engineer can build against. It has to become an assertion with three parts: a subject, an action, and an observable result.

Take the SEC's audit-trail language. The rule requires a complete time-stamped audit trail that includes all modifications to and deletions of the record, the date and time of actions that create, modify, or delete the record, and the identity of the individual creating, modifying, or deleting the record, in a way that will permit re-creation of the original record if it is modified or deleted [2].

That single sentence is at least four separate assertions:

Every create, modify, and delete on a covered record produces an audit entry. Subject: any covered record. Action: create, modify, delete. Observable: an audit row exists.

Each entry carries a timestamp. Observable: the row has a time field, populated, in a defined zone.

Each entry names the individual who acted. Observable: the row has an actor identity, and it is the real actor, not a service account and not an impersonated customer.

The original is recoverable after modification or deletion. Observable: take a record, modify it, and reconstruct the prior state from the trail alone.

That fourth one is the interesting case, because it is the one most systems fail and the only one that requires an actual test rather than a schema inspection. You cannot satisfy it by looking at the code. You have to run the sequence and check that the reconstruction works.

Step three: watch the three words that hide gaps

Three patterns in regulatory text account for most of the gaps we find.

"Any." The Safeguards Rule requires multi-factor authentication "for any individual accessing any information system" [1]. Teams implement MFA on the customer-facing login and leave it off the internal admin console, the reporting tool, and the database bastion. Every one of those is an information system and every one of those is accessed by an individual. "Any" carries most of the meaning in that sentence and it is routinely read as "the main one."

"All." Encryption obligations typically say all customer information held or transmitted, both in transit over external networks and at rest [1]. Teams check the primary database, which is encrypted because the cloud provider turns it on by default, and never check the backups, the exports, the analytics replica, the log aggregator, or the CSV somebody generates for a monthly report. "All" includes the copies.

The passive voice. "Records must be preserved" does not say by whom or where, and passive constructions let a requirement be missed by both the application and the infrastructure, with each side assuming the other owns it. When you convert a passive obligation, name the owner explicitly, because the regulation will not.

Step four: trace every check back to a sentence

Each check you write should carry a reference to the specific provision it exists to satisfy. Not "compliance test" but the section and clause.

This matters for two reasons. The first is that it makes the mapping auditable. A reviewer, internal or external, can read your check suite and your obligation list together and find the ones with no check attached. Without the trace, verifying your coverage means reverse-engineering intent from test names, which nobody will do properly.

The second reason is maintenance. Regulations change. When a provision is amended, you want to find every check that depends on it in one search, rather than hoping somebody remembers. The proposed HIPAA Security Rule update is a good example of why: it would move encryption from an addressable specification to a required one, which changes the assertion but not the topic. A traced suite makes that a targeted edit. An untraced one makes it a long search through old code.

Step five: write the check before the implementation

This is the ordering rule from eval-driven development and it matters more here than in ordinary work.

If the check is written after the implementation, it encodes what the implementation does. Someone reads the code, sees that deletes are logged, and writes a test asserting that deletes are logged. The test passes. It proves nothing, because the standard was copied from the thing being measured. In a compliance context that is actively harmful, because it produces a passing result that a reviewer will reasonably read as evidence.

Written from the obligation first, the same check starts from "the trail must permit re-creation of the original record" and frequently fails on the first run. That failure is the entire value. It is the moment you learn that your soft-delete drops the prior field values rather than preserving them, which is a thing nobody would have discovered by reading their own code.

What this looks like when it is done

At the end you have three artefacts that fit together: a list of obligations with quoted text, a set of assertions derived from them, and a check suite where every check names its source provision. Coverage becomes visible, because an obligation with no check attached is obvious immediately rather than hidden.

That visibility is the real deliverable. Most teams cannot answer "which of our obligations are enforced by something that runs" and the honest answer is usually "we do not know." Getting to a state where the answer is a list is most of the work.

Our page on audit trails that satisfy an examiner works through the logging obligations in this form, and get in touch if you want help building the mapping for your own product.