Regulatory and Compliance for Software Teams

What does regulatory and compliance mean for a software team?

Regulatory and compliance, for a software team, is the practice of identifying which laws, contracts and standards apply to a product, translating each one into concrete technical controls, and keeping evidence that those controls work. The rules belong to regulators and card networks; the controls and the evidence belong to engineering.

The two words describe different things. Regulatory refers to obligations set by law or a regulator, such as a federal rule or a state insurance code. Compliance is the ongoing state of meeting those obligations, plus any contractual standards a customer or partner imposes.

For a software vendor the obligation usually arrives through the customer. A covered entity signs a business associate agreement, a merchant passes card data, or an insurance licensee names you as a third-party service provider. Each of those relationships pulls specific duties into your codebase.

Which frameworks apply in healthcare, fintech and insurance?

The framework depends on the data you handle and who you handle it for. Four frameworks are the main ones for US software that touches health, payment or insurance data.

• Healthcare: HIPAA's Security Rule applies to covered entities and their business associates. It describes outcomes and leaves several technical controls to a documented risk decision rather than naming them outright.
• Consumer finance: The FTC Safeguards Rule at 16 CFR 314.4 requires financial institutions under FTC jurisdiction to use multi-factor authentication for any individual accessing any information system, and to encrypt customer information both in transit over external networks and at rest.
• Payments: PCI DSS comes from the PCI Security Standards Council. Version 4.0.1, published in June 2024, has been the only active version since v4.0 retired on 31 December 2024.
• Insurance: The NAIC Insurance Data Security Model Law (Model #668) asks licensees to notify the insurance commissioner within 72 hours of determining that a cybersecurity event occurred. Each state enacts its own version, so the statute a customer quotes may differ from the model.

The practical difference is in how prescriptive each one is. The Safeguards Rule and PCI DSS name specific controls. HIPAA leaves more room for judgment, and the insurance rules exist only as state law, so the exact wording depends on where the customer is licensed.

Where do the frameworks ask for the same control?

Most controls overlap, which is why one well-designed control set can serve all four frameworks. The comparison below shows the shared control areas and how the emphasis differs between them.

• Risk assessment: Every framework expects a documented assessment of threats to the data. Write one assessment that covers all data classes and update it when the system changes, rather than keeping one per framework.
• Strong authentication: The finance rule names multi-factor authentication outright, and payment and healthcare reviewers expect it as good practice. Apply it to every workforce login, console and admin API.
• Encryption: The finance rule requires it in transit and at rest. Healthcare and payment reviewers expect the same, so encrypt everywhere by default and document any exception.
• Activity logging: All four expect a record of who accessed what. One structured audit event format, written by the application and stored outside the reach of normal users, serves every reviewer.
• Vendor oversight: Healthcare uses business associate agreements, finance and insurance use service provider contracts. Keep one vendor register with the contract type, the data shared and the review date.
• Incident notice: Each framework sets its own clock and its own recipient. Build one incident runbook with a table of who must be told, by when, under each framework.

Write each shared control once, at the strictest wording that applies, and tag it with every framework it satisfies. A single authentication control written to the finance rule standard also answers the payment and healthcare questions about it.

Laws, contracts and attestations

Not every item a buyer lists is a law, and the difference changes who checks it. HIPAA, the Safeguards Rule and state insurance codes are laws enforced by regulators. PCI DSS is a contractual standard that card brands and acquiring banks require of merchants and service providers.

SOC 2 is different again. It is an attestation report that an independent CPA firm issues against the AICPA Trust Services Criteria. No regulator requires it, but enterprise buyers may ask for one in procurement.

No federal agency certifies software as meeting HIPAA or the Safeguards Rule. A vendor claim of being certified under either is a red flag. What a buyer can review is the control design, the test results and any third-party reports that exist.

This distinction shapes the evidence. A regulator asks whether you met the rule. A card brand asks whether your assessment passed. A buyer reading a SOC 2 report asks whether the auditor tested the controls it cares about. One control set can feed all three, but each audience reads it differently.

How do you turn a rule into a sprint-ready requirement?

You turn a rule into a requirement by rewriting it as a testable statement with an owner, an acceptance test and a named evidence artifact. The six steps below keep the trail from regulation to code intact.

• 1. Scope the data: List every data class the product touches, such as ePHI, cardholder data, nonpublic personal information or licensee data, and the systems that store or move it.
• 2. Select the frameworks: For each data class and customer type, record which framework applies and why.
• 3. Write control statements: Rewrite each obligation as one sentence a tester can check, for example "Every console and API login requires a second factor", with the framework references attached.
• 4. Map controls to backlog items: Link each control to the stories, infrastructure modules and policy checks that implement it, so a code change shows which control it touches.
• 5. Define the evidence: For each control, name the artifact that proves it, such as a CI policy result, an identity provider export or a sample log event.
• 6. Review on change: Re-run the mapping when a new integration, data type or customer segment arrives, not only once a year.

A worked example shows the shape. The obligation "encrypt customer information at rest" becomes the control "All databases, object stores and backups holding customer data use encryption with keys managed in the cloud key service". Its test is a policy check that fails the build on an unencrypted resource, and its evidence is the check result for each release.

The control statement is the unit that matters. Frameworks change, but a well-written control usually survives a revision with a reference update rather than a redesign.

How can you shrink what falls in scope?

You shrink scope by keeping regulated data out of systems that do not need it. Every system that stores or moves the data inherits the controls, so fewer systems means less to build and prove.

• Tokenize card data: Let a payment provider collect card numbers in its own hosted fields and return a token, so your servers never see the full number.
• Separate regulated stores: Keep health, financial or insurance records in dedicated databases and accounts with tighter access, instead of mixing them with general product data.
• Strip data from logs: Mask or drop sensitive fields before they reach application logs, error trackers and analytics tools.
• Use synthetic test data: Give staging and developer environments generated records, so they stay outside the regulated boundary.
• Limit support tooling: Give support staff views that show only the fields they need, rather than raw database access.

The trade-off is integration effort. Tokenization and separate stores add services and network paths, but they usually cost less than applying the full control set to every system in the product.

What should a regulated delivery pipeline produce?

A regulated delivery pipeline should produce evidence as a side effect of normal work. When proof comes from the build system and the cloud account, nobody has to assemble it by hand before a review.

• Change records: Pull requests with required reviews, linked tickets and the control tags they affect.
• Policy check results: Infrastructure-as-code scans that block public storage, unencrypted volumes or open admin ports before merge.
• Dependency and build records: Software composition results and build provenance, following the practices in NIST's Secure Software Development Framework.
• Access exports: Scheduled exports of who holds which role, and offboarding events matched against HR records.
• Log samples: A representative audit event for each sensitive action, with actor, action, resource, time and source.
• Payment page integrity: For card flows, an inventory of the scripts that run on payment pages and alerts when those pages change unexpectedly.

Keep the evidence in a store with its own access rules. Evidence that engineers can quietly edit is weaker than evidence written once by the pipeline.

Where multi-framework programs go wrong

The weak points in a multi-framework program sit at the seams between teams and rulebooks, not inside one control. This failure-point list is worth checking before a buyer's security review.

• One spreadsheet per framework: Separate healthcare, payment and insurance trackers drift apart, and the same control is tested three times with three answers.
• Healthcare habits applied to finance data: Teams used to judgment-based healthcare controls treat encryption and MFA as optional, then fail a finance review where both are mandatory.
• Card data in the wrong place: Card numbers land in logs, analytics or support tools, pulling those systems into payment scope.
• State variation ignored: An insurance customer cites its own state's version of the model law, and its deadline or exemptions differ from the model text.
• Evidence that ages: A risk assessment, network diagram or vendor list dated before the last major release no longer matches the system.
• Certification language in sales copy: Claims of being "HIPAA certified" or "PCI certified" invite questions no artifact can answer.

How Agnotic can help

Products that serve regulated buyers need one control set that answers several rulebooks at once. Agnotic Technologies builds that control set into the client's software: identity and MFA, encryption and key handling, audit events, policy checks in CI and the evidence store reviewers read.

Agnotic can also map a product's data flows against the healthcare, finance, payment and insurance frameworks that apply, write the control statements and wire each one to the backlog and pipeline. The legal reading of which rule applies stays with the client's counsel.

Sources

• 16 CFR 314.4: FTC Safeguards Rule elements of an information security program
• PCI Security Standards Council: PCI DSS v4.0.1 published
• NAIC: Insurance Data Security Model Law (Model #668)
• NIST SP 800-218: Secure Software Development Framework