Blog & Insights

Security and Compliance on a Custom Build, in Plain Terms

What SOC 2 Type 2 means for you as a client, how a custom system handles HIPAA, PCI, or audited data without becoming a compliance project, where your data lives, and the questions to ask any firm before they touch it.

Security is the topic owners know they should ask about and are not sure how. The vocabulary is unfriendly, the stakes are obvious, and every firm says “yes, we take it seriously.” This post is the plain version: what the credentials mean, how a custom system is built to handle regulated data, where your information actually lives, and what to ask so you can tell a real answer from a reassuring one.

What SOC 2 Type 2 means for you

We are SOC 2 Type 2. In plain terms, an independent auditor examined how we handle client data, access, and change, not once but over a period of months, and confirmed that the controls we describe are the controls we run. Type 1 says the controls exist. Type 2 says they were operating.

For you, it means three practical things. Our people’s access to your systems is granted on purpose, reviewed, and removed when it should be. Changes to what we build go through a controlled process rather than someone pushing to production on a whim. And there is evidence of all of it, which matters the day your own auditor, insurer, or biggest customer asks who has touched your data.

Where your data lives

Inside your environment. We build in your cloud accounts, on the major public clouds, and your data stays in systems you own and can revoke our access to at any time. We do not copy client data into a shared environment of ours. For work where data cannot leave your walls at all, including some AI work, we can run a private language model inside your environment so nothing goes to an outside service.

How a system handles regulated data

Owners worry that HIPAA, PCI, or an auditor’s requirements will turn a software project into a compliance project. Handled the right way, they do not. They become part of the design:

  • Access control decides who can see and do what, by role, and enforces it in the system rather than by policy.
  • Audit trails record who did what and when, automatically, so the evidence exists without anyone remembering to create it.
  • Encryption protects data at rest and in transit as a matter of course.
  • Retention and deletion rules are built in, because a regulator’s question is often not “do you have it” but “why do you still have it.”
  • Separation of environments keeps real data out of development and test.

The principle is that when your industry has rules, the system enforces them. A process that depends on people remembering the rule will fail an audit eventually. A system that will not let the rule be broken passes every time.

We have built systems that handle protected health information, regulated financial data, and audited compliance workflows, including anti-money-laundering work where the audit trail is the product.

What it costs

More than a system without those requirements, and we say so up front. On our pricing table, security-conscious and compliance-heavy systems have their own row, because the controls and the testing are a real share of the budget rather than something bolted on at the end. Planning them from the first week is what keeps that share reasonable. Discovering them in month five is what makes compliance expensive.

Before you sign, with any firm

Six questions, and the answers you want:

  1. Are you SOC 2 audited, and which type? Type 2, with a report they will share under NDA.
  2. Where will our data live during the project? In your accounts, not theirs.
  3. Who on your team will have access, and how is it removed? Named people, granted on purpose, revoked at the end.
  4. How do changes reach production? Through review and a controlled deployment, not from a laptop.
  5. Have you built for our regulation before? Specific examples, not a general yes.
  6. Will the system enforce our rules, or will we? The system.

And one for yourself: will you sign their NDA before the first substantive conversation? We will sign yours. It should not be a negotiation.

The short version

Security on a custom build is not a feature you add. It is how the system is built, who is allowed to touch it, and the evidence that both are true. Ask for the report, ask where the data lives, and ask who enforces the rules. The firms with real answers will be glad you asked.

More like this, in your inbox. Subscribe for our latest thinking, resources, and events.

Get started

Want results like these?