Pass Security Review Once: Inheriting Compliance Posture Across Apps
Every new app arrives at the review queue as a fresh unknown, with its own questionnaire, its own evidence, its own controls to re-prove. When AI generates apps faster than any queue can drain, that per-app tax becomes the bottleneck. There is an architectural way out.
If your team ships software, you know the drill. Each new app shows up at the security review queue with nothing behind it. A questionnaire gets filled out, screenshots and configs get gathered, controls get re-proven from scratch. The premise of this guide is that you can stop repeating that work. With the right architecture, every new app can inherit compliance posture from a boundary you approved once, so it arrives already covered.
The recurring tax on every app
Security review is a loop that runs per app, and each pass is expensive. Evidence collection is one of the most resource-intensive parts of a SOC 2 audit. Organizations routinely dedicate multiple full-time employees to tracking down screenshots, configurations, and policy documents scattered across systems and teams. The bar is rising too. Point-in-time assessments no longer satisfy enterprise buyers, who increasingly expect continuous compliance between audit cycles rather than a once-a-year snapshot.
The same tax lands on the sell side. A single vendor security questionnaire can eat eight or more hours of manual work per response, and comprehensive ones run 10 to 40 hours. A mid-market vendor may field 50 to 100 of them a year. Security review has become a standard step in B2B buying, and a slow response stalls the deal. Whether you are the reviewer or the reviewed, the unit of cost is per app, and that is the number AI is about to multiply.
What it means to inherit compliance posture
Inheritance is already how layered compliance works. When you build on a compliant provider, you don't re-audit their data-center physical security. You rely on their report. As auditors put it, reviewing a subservice organization's SOC 2 report is "more efficient than performing your own audit" and is "as effective as performing your own tests of controls but does not utilize any of your own resources." That is inheritance: a control someone else enforces, that you get credit for without re-proving.
SOC 2 formalizes both halves of that arrangement. Complementary subservice organization controls are the controls the underlying boundary performs on your behalf. Complementary user entity controls are the ones you still have to run yourself. Inheritance is real and bounded. You inherit exactly what the boundary enforces, and you own what it hands back to you.
Applied to your own apps, the definition gets concrete. A control is inherited when the runtime the app lives in enforces it, with nothing written into the app's own code. Isolation, audit logging, egress policy, identity: if the boundary enforces them, they are already true for every app running inside it. The app cannot opt out, so you never have to re-verify each one. You checked the control once, at the boundary, and every app inside gets the result for free.
Stop proving that a control exists in each app. Prove that the boundary all apps run in enforces it. Verify the boundary once and every app inside inherits the result, including the ones that don't exist yet.
Why per-app review breaks at AI speed
When a human wrote each app over weeks, per-app review roughly kept pace with generation. AI code generation breaks that ratio. Apps now arrive faster than any reviewer can clear them, and the queue has only two failure modes. Launches pile up waiting for a review that cannot scale, or review gets quietly skipped and unreviewed apps reach production data. The skipped ones don't disappear. They resurface later as SOC 2 findings, shadow systems nobody can attribute, or the app that touched customer records with no log of what it did.
Neither outcome is acceptable, and "review faster" fixes neither. The durable move is to review less, structurally, by changing what the unit of review is.
Approve the boundary, and the apps come with it
That is the reframe. Rather than reviewing each app against your controls, you run every app inside one approved boundary that enforces isolation, audit, and policy at runtime, and you review the boundary. Your compliance posture then attaches to the runtime and stops being a property of any individual artifact. Prove the controls once, where they are enforced, and each app inherits them by construction. Security review turns from a per-launch gate into a one-time approval of the environment everything runs in, which is the only version of this that survives contact with AI-speed generation.
Sources
- "SOC 2 audit transformation: A modern approach to continuous compliance" (evidence collection burden; point-in-time vs. continuous compliance), Thoropass · thoropass.com/blog/soc-2-audit
- "The Hidden Cost of Security Questionnaires Done Manually" (hours per questionnaire; security review as a B2B buying gate), Narad · narad.io
- "Security Questionnaire Fatigue: Stats & How to Fix It" (10 to 40 hours per questionnaire; annual questionnaire volume), Steerlab · steerlab.ai
- "Monitoring Subservice Organization Controls: SOC Guidance" (control inheritance; CSOCs and CUECs), Linford & Co. · linfordco.com
- "SOC 2 Trust Services Criteria (TSC) Explained" (AICPA Trust Services Criteria and SOC 2 scoping), Schellman · schellman.com