Don't Fear the Audit: Hold the Certificate From Day One
Build confidence before researchers log in. This guide explains how to create a clean RONIN Isolate environment, connect continuous compliance and security tools, complete an independent audit and apply proportionate controls across research workloads.
For many research institutions, the biggest driver for a new cloud environment isn't speed or features. It's fear. Fear of an audit, fear of a finding, and in the US, fear of the False Claims Act if a grant was won on compliance promises that weren't kept.
That fear is reasonable. But there's a better way to handle it than locking everything down and hoping. In this post we'll walk through an approach we recommend: build the secure environment, get it independently audited before anyone logs in, and keep it continuously monitored from then on. Don't fear the audit; hold the certificate from day one.
This post is for central research IT, security and compliance teams.
The uncomfortable truth about compliance
Here's the thing nobody puts on the architecture slide: in our experience, around 80% of the compliance effort goes into the paperwork, people and processes around the IT system, not the technology itself. The frameworks back that up. HHS's own Security Rule matrix lists 42 implementation specifications, and 33 of them (79%) are administrative or physical safeguards rather than technical ones (HHS, Security Standards Final Rule, 68 Fed. Reg. 8334, Appendix A). Over in NIST SP 800-53 Rev 5, only 98 of the 300 base controls (about a third) sit in the technical access control, audit, identification and system protection families (NIST SP 800-53 Rev 5 catalog).
The technical controls matter, of course. But auditors also want to see refreshed policy documents, records showing you held the meetings you said you would, training completion, background checks for your users, access reviews and incident response plans. A beautifully configured set of SCPs won't produce any of that.
AWS says as much about its own foundation. The Landing Zone Accelerator page notes: "This solution will not, by itself, make you compliant." Under the shared responsibility model, AWS secures the cloud and you secure what you put in it, including how you configure and operate it.
The approach: build, audit, then open the doors
Most environments go live first and get audited later, which means the first audit is also the first time anyone finds out what's missing. We'd flip that around.
Build, audit, then open the doors, with continuous monitoring feeding gaps back into the process.
1. Start clean
Start with a new, separate AWS account and connect it to your compliance platform before anything else goes in.
If you connect an existing environment, or a child account carrying a heap of inherited integrations and controls, your compliance tool will probably light up with thousands of things it wants changed. Starting clean makes it much easier to tell what's actually required from what's just baggage.
Going greenfield doesn't mean ignoring institutional tools. Your security tooling, network templates (for example Transit Gateway patterns) and identity provider can all be connected deliberately, one at a time, so you know what each one adds.
2. Build the Isolate
RONIN Isolate is our locked-down environment for sensitive data: no direct internet access, controlled data ingress and egress, and researcher desktops and tools inside the boundary. Because it's built from a standard RONIN deployment rather than a one-off design, every Isolate starts from the same known configuration. That's the standard-template audit-friendliness that leadership is usually looking for.
3. Turn on continuous compliance
We recommend pairing the environment with a continuous compliance platform such as Vanta. Tools like this connect to your cloud accounts, HR systems and identity provider, test controls continuously, and collect evidence automatically: policy acceptance, training, background checks, access reviews and so on.
We use Vanta ourselves. It helped us get through our own SOC 2 in record time, and it gives us continuous monitoring and self-audits rather than a scramble once a year.
4. Keep your CSPM too
If you already run a cloud security posture management (CSPM) tool such as Wiz, keep it. CSPM and continuous compliance tools do complementary jobs:
| Continuous compliance (e.g. Vanta) | CSPM (e.g. Wiz) | |
|---|---|---|
| Main question | Can we prove we meet framework X? | Is anything in our cloud misconfigured or exposed? |
| Covers people and process | Yes: policies, training, checks, reviews | Mostly no |
| Covers cloud configuration | Yes, mapped to framework controls | Yes, in depth |
| Audit evidence | Collected and organised for auditors | Supporting evidence |
| Best used for | Getting and keeping certified | Finding and fixing risk fast |
Plenty of our customers run both.
5. Get audited before anyone logs in
With controls and paperwork in place, bring in an independent auditor to assess the environment before onboarding a single researcher. When the first grant application or data request lands, you can point to a passed audit rather than a plan.
Tiers: strict where needed, not everywhere
Health sciences research covers a lot of ground. Some projects handle HIPAA-protected health information. NIH-funded work involving controlled data may need NIST SP 800-171. Defence-related research may need CMMC. And much research needs none of these.
Forcing everything into the strictest tier causes two problems. It slows down and frustrates researchers who don't need it, and it drives them to workarounds like personal Dropbox, which is a much bigger compliance risk than a sensible tier would have been.
RONIN can be deployed into separate AWS accounts configured for each compliance level. That fits the way the AWS SRE groups accounts into organisational units with their own guardrails:
A quick note on HIPAA: there's no such thing as a "HIPAA certification" for a cloud service. AWS maintains a list of HIPAA eligible services, and under a Business Associate Addendum you can process PHI in those services, provided you configure them to meet HIPAA requirements. Your audit is about how you've done that.
Why this works for audit-friendliness
- Standard templates. Every environment is built the same way, on an AWS-standard foundation with a standard RONIN deployment on top.
- Evidence from day one. Continuous monitoring means evidence is collected before you need it.
- A clean scope. A greenfield account means the auditor reviews what you built, not ten years of history.
- Proportionate controls. Tiers keep strict controls where they're needed and keep researchers on the platform.
Next steps
If an upcoming audit, grant or data request is keeping you up at night, get in touch. We're happy to talk through what's worked for us and our customers, with or without RONIN.
Sources
- U.S. Department of Health and Human Services, "Health Insurance Reform: Security Standards; Final Rule," 68 Fed. Reg. 8334 (20 Feb 2003), Appendix A to Subpart C of Part 164, p. 8380: govinfo.gov. See also 45 C.F.R. § 164.308, § 164.310 and § 164.312.
- NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, OSCAL catalog. Technical families counted: AC, AU, IA and SC.
