Know who can reach your customers' data, on every release.
Release Verification & Readiness
An automated gate that runs on every release of your web application. It replays your app's requests as the wrong user, the wrong role, and the wrong customer, checks what is inside the responses, and gives each release a GO or NO-GO recommendation with the evidence your customer's security review asks for.
portal.sample-tenant.example · release 4.18.0 · staging
NO-GO
1 hard finding · 2 medium · 0 inconclusive
HARD cross-tenant read
GET /api/invoices/:id as tenant B admin
returned 1 row owned by tenant A
positive control: tenant A reads own row ✓
maps to CAIQ IVS-06.1 · ASVS 8.2.2
MED role hidden in UI only
/reports/billing answers a viewer role
PASS secrets in client bundles: none
What you're buying
Evidence that holds between reviews.
Teams call us when a customer's security review, a pentest report, or a fast-moving codebase raises a question about access they can't answer with evidence yet.
Customer review
An answer to "how do you keep customers apart?"
Security questionnaires ask how one customer is kept from another's data (CAIQ IVS-06), how changes are tested before release (SOC 2 CC8.1), and how access control is verified (OWASP ASVS V8). We hand you evidence from your own running application, mapped to the rows you are answering.
AI-built code
Proof the access rules still hold after every release
Code written quickly, by people or by coding assistants, often ships with an access rule missing on one table or one endpoint. The gate checks every path on every release, so a rule that goes missing is caught before your customer finds it.
Fixed findings stay fixed
A finding closes once, and stays closed
After a pentest or a customer review, each authorization fix gets a check that runs on every release. A finding closes only when the fix is traced end to end, and the check that proves it runs on every release after that.
Release decisions
A clear GO or NO-GO before you ship
Each release gets a GO, GO-with-findings, or NO-GO recommendation with the evidence behind it. Your team makes the release decision; you make it knowing what changed.
What the gate checks
Who can reach what, and what leaks.
Built against your schema and your roles, run against your staging, on every release.
Authorization
Every request, replayed as the wrong person
Each read your application serves is replayed with no session, as a lower role, and with another tenant's id. Broken object-level authorization (BOLA, also called IDOR) shows up as data that should have been refused.
Tenant isolation
Every path to customer data, from the schema
The list of what to check is derived from your database schema, so a new table is covered the day it lands. For each path we ask one question: can anyone outside this customer read this customer's data?
Data leaks
What is inside the responses
API responses, server-rendered pages, and the JavaScript your app ships are scanned for credentials, server secrets, stack traces, and other people's private fields.
Roles in the UI
Restrictions enforced by the server
Every control on every page is pressed for every role. A role that is only hidden in the interface, while the server still answers, is a finding.
The rest of a release
Functional, browser, accessibility, and load
End-to-end journeys, a browser and device matrix including mobile Safari, accessibility checks against WCAG AA, load limits measured, and prompt-injection checks where the app uses AI.
Traceability
From requirement to release
Requirements, gaps, and decisions kept in a register with stable ids, so every finding, fix, and verdict traces back to what the application is supposed to do.
How we know the check isn't blind
A gate that can't pass by accident.
An access check that finds nothing proves nothing if the other customer had no data to find. Every check starts with a positive control: the rightful owner proves they can read the record first, and only then does a refusal for everyone else count as isolated. Where the owner can't, the result is reported as unproven, never as a pass.
Known failures stay in the gate as must-detect cases, so if the gate ever stops seeing them, it fails. Waivers carry a reason, a reviewer, and a date, and expire. Known debt is recorded and can only shrink. The gate runs with no automatic retries, because a flaky gate is a gate you can't trust.
We run the same gates on the software we build and operate.
Engagements
Assess, build, then run it every release.
Starting prices for one production application with its API and sign-in. We return a fixed scope after a discussion and an NDA.
Start here
Release Readiness Assessment
From $7,500
One to two weeks on one application in staging: authorization and tenant-isolation baseline, a GO/NO-GO scorecard, and evidence mapped to the questionnaire you are answering.
Build
Gate Build
From $15,000
The gate built against your schema and roles on our infrastructure, pointed at your staging, and run once in full with a baseline report. Sized by endpoints, roles, and tenants. The assessment fee is credited if you buy the build within 30 days.
Run
Ongoing verification
From $3,000 / month
After a Gate Build, the gate on every release with a GO/NO-GO recommendation, from a monitoring tier up to the full practice with fix verification and requirements governance. Higher tiers can run your app's checks inside your own CI.
Not a penetration test, an independent assessment, or a certification. Where your customer requires an independent test, our testing partner provides it.
Questions
Release verification, answered
What is Release Verification & Readiness?
An automated gate that runs on every release of your web application and checks whether anyone can reach data they should not: across roles, across customers, and through the responses your app sends. Each release gets a GO, GO-with-findings, or NO-GO recommendation with the evidence behind it, mapped to the security questions your customers ask.
Is this a penetration test?
No. A penetration test is a point-in-time attempt to break in, done by an independent tester. Release verification is a regression gate that keeps known access-control failures from coming back, release after release. Where your customer or auditor requires an independent test, our testing partner provides it, and the gate keeps those findings closed afterward.
Is it independent verification and validation (IV&V)?
No. IV&V requires the verifier to be independent of whoever builds the system, and we also build and operate software ourselves. We describe this as verification and release readiness, and we never present it as an independent assessment or a certification.
How can a check prove something is isolated, rather than just empty?
Every check starts with a positive control: before "no rows" counts as isolated, the rightful owner has to prove they can read those rows. If they cannot, the result is reported as unproven, never as a pass. Known failures are kept as must-detect cases, so the gate fails if it ever stops seeing them.
Does it run against production?
The full gate runs against staging. In production we run read-only checks using test tenants and planted records you provide, nothing that writes, loads, or calls a third-party service, and only with your written authorization. If real customer data ever appears in a result, it is not stored, it is reported by type only, the run stops, and we tell you.
Which frameworks and questionnaires does the evidence map to?
The ones you are answering. Typical rows are CAIQ IVS-06 (tenant segmentation), SOC 2 CC8.1 (tested changes), OWASP ASVS 5.0 V8 (authorization), PCI DSS 6.2.4 (access-control bypass), and NIST SSDF PW.8 (testing executable code).
How do you handle access to our staging environment?
We work only with test accounts and test tenants you create for us, on staging. The credentials are stored encrypted on our infrastructure, used only by the gate, and revoked at the end of the engagement; you can rotate them at any time. We never ask for production administrator access, and we answer your own vendor security questionnaire as part of onboarding.
What do you need from us, and how long does it take?
A staging URL, two test tenants, a seed account for each role, and written authorization to test. The Release Readiness Assessment takes one to two weeks from the day access works. Gate Build timing depends on the number of endpoints and roles and is fixed in the scope.
What are the contract terms for ongoing verification?
The monitoring tier runs month to month with 30 days' notice. The Managed and Embedded tiers start with a three-month minimum, then continue month to month with 30 days' notice. Every ongoing tier follows a Gate Build.
Who does the work?
Our QA automation engineer builds and runs the gate, and the person who scopes the engagement owns the outcome and the evidence. We run the same gates on the software we build and operate. We take a limited number of engagements at a time so each release gets a real review.
What stack does it work with?
Web applications and APIs with role-based or tenant-based access, including apps on Postgres with row-level security (for example Supabase), Next.js and similar frameworks, and REST or RPC APIs. The gate runs on our infrastructure against your staging, using test accounts and tenants you provide. On the Managed and Embedded tiers, your application's checks can also run inside your own CI.
How is it priced?
The Release Readiness Assessment starts at $7,500 and the Gate Build at $15,000, sized by endpoints, roles, and tenants. Ongoing verification follows a Gate Build, starts at $3,000 a month, and depends on how often you release and how much of the practice you want. We return a fixed scope after a discussion and an NDA.
A security review asking how you keep customers apart?
Request a discussion and tell us who is reviewing you: a customer, an operator, an agency, or an auditor. We'll tell you what evidence their review expects.
Request a DiscussionNot sure where to start? Tell us where you are.
Evaluating your security posture before a funding round, compliance deadline, or enterprise deal?