Stage Gates: Security Requirements by Phase
- Executive Summary
- Working Knowledge
- Technical Spec
Phased Security Investment
Not every security control needs to be production-ready on day one. The stage gate model defines which security capabilities are required at each launch phase, allowing ReGenesis to balance speed-to-market with enterprise credibility. The key insight is knowing what must be real versus what can be documented as a roadmap item -- enterprise buyers accept certain gaps if you can demonstrate a credible plan and timeline.
There are four stages: MVP0 Demo (proving the concept works with basic protections), Pilot (McKinsey-ready with the controls that close an enterprise deal), GA (full enterprise-grade security for broader market launch), and Global (international compliance for expansion beyond the US market). Each stage builds on the previous one, and security investments compound -- nothing built for an earlier stage is discarded.
The critical insight for the business is that the Pilot stage is the most consequential. McKinsey will not sign without SOC 2 Type I, SSO/MFA, a signed DPA, a completed penetration test, and a documented incident response plan. These are non-negotiable, and the timeline to achieve them by Q3 2026 is aggressive but achievable with the right prioritization.
Stage Gate Overview
Stage Progression with Gate Criteria
Gate 1: MVP0 to Pilot -- Go/No-Go Criteria
| Criterion | Go Condition | No-Go Condition |
|---|---|---|
| Encryption | TLS 1.2+ and AES-256 at rest verified | Any data stored or transmitted unencrypted |
| Access control | RBAC enforced for all 6 roles, tested | Broken access control or untested permissions |
| Security Officer | Named individual with documented responsibilities | No one owns security |
| Compliance platform | Vanta/Drata set up, evidence collection started | No compliance automation in place |
| SOC 2 readiness | Type I audit engagement signed, timeline confirmed | No auditor selected |
| SSO integration | SAML 2.0 working with at least one IdP (Okta or Azure AD) | SSO not functional |
| Pen test | Scheduled with reputable firm, scope defined | No pen test plan |
Gate 2: Pilot to GA -- Go/No-Go Criteria
| Criterion | Go Condition | No-Go Condition |
|---|---|---|
| SOC 2 Type I | Report obtained and shared with pilot clients | Report not yet obtained |
| Pen test | Completed, all critical/high findings remediated | Outstanding critical or high findings |
| SSO + MFA | Working in production for pilot client | Authentication failures or workarounds in use |
| DPA | Signed with all pilot clients, subprocessor list current | Unsigned or non-compliant DPA |
| Zero cross-tenant leaks | No incidents of data leaking between tenants during pilot | Any cross-tenant data exposure |
| Incident response | IR plan tested (at minimum tabletop), no gaps found | IR plan untested or with known gaps |
| SCIM | At least tested with one IdP; can be manual provisioning for pilot | No provisioning plan |
| Pilot feedback | Pilot client confirms security posture meets their requirements | Client security team raises unresolved concerns |
Gate 3: GA to Global -- Go/No-Go Criteria
| Criterion | Go Condition | No-Go Condition |
|---|---|---|
| SOC 2 Type II | Report obtained with clean opinion | Outstanding exceptions or qualified opinion |
| 3+ enterprise clients | At least 3 paying enterprise clients in production | Fewer than 3 clients (insufficient operational evidence) |
| Zero cross-tenant leaks | Zero incidents across all clients for 6+ months | Any cross-tenant exposure in the last 6 months |
| SCIM tested | SCIM working with at least 2 different IdPs | SCIM untested or failing with major IdPs |
| DR tested | Full DR drill completed successfully within RTO | DR untested or drill failed |
| Multi-region readiness | DR region validated, failover tested | No cross-region capability |
| EU compliance | GDPR Article 28 DPA template, SCCs in place, DPIA updated | Missing GDPR artifacts |
| Cyber insurance | $5M+ policy active | No coverage |
Stage 1: MVP0 Demo
Purpose: Demonstrate the platform works with minimum viable security. Used for internal demos, investor presentations, and early design partner conversations.
Timeline: Complete by Q1 2026
| Requirement | Description | Status | Can Be Staged? |
|---|---|---|---|
| TLS 1.2+ on all endpoints | All traffic encrypted in transit | Must be real | No |
| AES-256 encryption at rest | All database storage encrypted | Must be real | No |
| Basic RBAC (6 roles) | Role definitions and permission enforcement | Must be real | No |
| Data deletion capability | Ability to delete user data on request | Must be real | No |
| Password hashing (bcrypt/argon2) | Secure credential storage | Must be real | No |
| Input validation | Basic XSS and injection prevention | Must be real | No |
| Environment separation | Dev/staging/prod not sharing data | Must be real | No |
| Security Officer named | Identified person responsible for security | Documented | Yes (can be fractional) |
At MVP0, the platform does NOT need: SOC 2, SSO, MFA, SCIM, formal DPA, pen test, audit logs, WAF, or DR plan. But the fundamental protections -- encryption and access control -- are essential from the start, because retroactively adding these is extremely painful.
Stage 2: Pilot (McKinsey)
Purpose: Meet the minimum security bar for a Fortune 500 pilot engagement. McKinsey's security team will evaluate ReGenesis before approving the pilot.
Timeline: Complete by Q3 2026
| Requirement | Description | McKinsey Expectation | Can Be Staged? |
|---|---|---|---|
| SOC 2 Type I report | Point-in-time audit of control design | Required for approval | No - must be completed |
| SSO (SAML 2.0) | Integration with McKinsey's identity provider | Required | No - must work on day one |
| MFA for all users | Multi-factor authentication | Required (enforced by their IdP if SSO) | No |
| Signed DPA | Data processing agreement with subprocessor list | Required for legal | No - must be signed |
| Penetration test | Third-party pen test with remediation of critical/high | Required, report sharable | No - must be completed |
| Incident Response plan | Documented IR procedures and contacts | Required, can be reviewed | No - must be documented |
| DPIA | Data Protection Impact Assessment for AI processing | Required for GDPR | No |
| Audit logging (auth + data access) | Authentication and data access events logged | Required | No - must be operational |
| Named security contact | Identified person for security questions | Required | No |
| Encryption certification | Documented encryption architecture | Required | Report format OK |
| Data residency | All data in specified region (us-east-1) | Required | No - must be enforced |
| 3-layer governance model | Operational, management, strategic governance | Expected (mirrors their approach) | Can be documented |
Based on McKinsey's known vendor requirements (similar to their Lilli platform security posture):
- Named Security Officer - Not a shared responsibility; someone owns it
- Encryption everywhere - At rest AND in transit, no exceptions
- Pen test report - Must be from an independent third party
- 3-layer governance - They will look for operational + management + strategic security governance
- DPA with specific terms - They have their own DPA template; negotiation expected
These cannot be deferred. Missing any one of these will block the pilot.
Stage 3: GA (General Availability)
Purpose: Full enterprise-grade security for broader market launch. This is the baseline for all Fortune 500 clients going forward.
Timeline: Q1-Q2 2027
| Requirement | Description | Can Be Staged? |
|---|---|---|
| SOC 2 Type II report | Operating effectiveness over 6+ months | No - must be completed |
| ISO 27001 certification | ISMS certified by accredited body | No |
| SCIM provisioning | Automated user lifecycle management | No - enterprise requirement |
| Full audit log UI | Self-service audit log access for enterprise admins | No |
| BYOK encryption | Bring Your Own Key for high-security tenants | Can offer as premium |
| Per-tenant encryption keys | Isolated encryption per organization | No - architecture requirement |
| Complete procurement packet | Full security documentation package | No |
| DR tested and documented | Documented and tested disaster recovery | No |
| Cyber insurance | $5M+ cyber liability coverage | No |
| Vulnerability management program | Documented scanning, patching, and remediation SLAs | No |
| Security awareness training | Documented employee training program | No |
| Background checks | For all employees with data access | No |
| Enterprise admin console | Self-service admin portal for enterprise clients | No |
| IP allowlisting | Optional IP restriction for enterprise tenants | Can offer as premium |
Stage 4: Global Expansion
Purpose: International compliance for expansion beyond the US market. Specific certifications triggered by market entry and client requirements.
Timeline: Q3 2027+
| Requirement | Trigger | Description |
|---|---|---|
| HIPAA compliance | Health/wellness coaching features | PHI handling requirements |
| FedRAMP | US government clients | Federal cloud security authorization |
| EU AI Act compliance | EU market entry | AI transparency and governance requirements |
| ISO 42001 | AI governance demand | AI management system certification |
| ISO 27701 | GDPR enhancement | Privacy information management |
| Multi-region deployment | Performance/compliance | EU region (eu-west-1), AP region |
| Data sovereignty | Client requirements | Data stays in specified geography |
| CSA STAR | Cloud-specific certification | Cloud Security Alliance assessment |
What Can Be Staged vs. What Must Be Real
Understanding this distinction is critical for resource allocation:
Must Be Real (No Shortcuts)
These controls protect actual data and cannot be documentation-only:
- Encryption (at rest and in transit) -- data is either encrypted or it is not
- Access control (RBAC enforcement) -- permissions are either checked or they are not
- Authentication (SSO, MFA) -- users are either properly authenticated or they are not
- Tenant isolation -- data is either isolated or it can leak
- Input validation -- injection attacks are either prevented or they are not
- Audit logging -- events are either captured or they are not
Can Start as Documentation
These controls have documented plans that are acceptable to reviewers, with implementation to follow:
- DR/BCP plan -- a well-documented plan is better than no plan, even if not yet tested
- Governance structure -- documented roles and responsibilities, even if part-time
- Training program -- a plan with scheduled dates is acceptable
- Vulnerability management -- a policy with SLAs, even before automated scanning
- Incident response -- a documented plan with contact trees
Can Be Staged as Roadmap Items
Enterprise buyers will accept these as future capabilities if the roadmap is credible:
- ISO 27001 (during SOC 2 Type II period)
- BYOK encryption (requires architecture, not a quick add)
- SCIM (enterprise can use manual provisioning initially)
- Multi-region (single region with backups is acceptable short-term)
- HIPAA/FedRAMP (only needed for specific market segments)