Common buyer questions answered from MIRMC's canonical engineering registries. Planned controls, missing certifications and unclaimed legal conclusions remain visible instead of being converted into sales yeses.
Anti-overclaim procurement surface
21 enterprise questions with source evidence.
This matrix is useful for security questionnaires and vendor review preparation, but it is not a signed representation, contract, certification, DPA or legal opinion. Customer-specific answers still require review.
A controlled/staged answer is intentionally not rendered as implemented. Network restrictions, SSO, SCIM, DR evidence, SLA and branch protection remain open until their own production evidence exists.
Questionnaire
Evidence-backed responses
security · tenant-isolation
Does the product enforce tenant-aware authorization?
Implemented
Organizations, memberships, tenant-scoped roles, protected subscription writes and RLS-backed boundaries are defined in the Agency SaaS foundation.
Agency billing and guarded Command Center mutations now validate request-session assurance server-side and reject enrolled users whose session can reach AAL2 but is still AAL1. Command Center MFA denials are recorded without persisting access tokens or TOTP values. Mandatory enrollment by sensitive role and universal RPC/RLS enforcement remain open enterprise work.
Controlled does not mean every account is under universal mandatory enrollment.
Repository evidence
supabase/functions/_shared/agency-stripe.ts
src/lib/admin-command-assurance.server.ts
src/lib/admin-command-execution-guard.server.ts
src/lib/admin-command-assurance.server.test.ts
scripts/check-enterprise-identity.ts
src/lib/enterprise-saas-readiness.ts
identity · sso
Is enterprise SSO available and production-verified?
Planned / open
MIRMC now contains a staged SAML SSO initiation/callback foundation plus explicit provider-UUID-to-organization binding and negative cross-tenant guards. Production remains planned because no live IdP has been registered and verified, and OIDC is not claimed implemented.
A tenant-scoped SCIM 2.0 Users foundation, hash-only organization credentials, SAML-bound first-login linking, AAL2 control plane and optional atomic ETag preconditions are staged. Production remains planned until a real IdP and SCIM client canary succeeds.
Are high-impact publications subject to independent approvals?
Controlled / staged
MIRMC now contains a staged tenant-scoped publishing authority with current-session AAL2, maker/checker separation, two independent approvals for production, approval expiry, exact source-commit binding and a service-only Cloudflare release-receipt boundary. Production activation is not claimed yet.
Are tenant IP/CIDR restrictions enforced end-to-end in production?
Planned / open
No production enforcement claim. Source architecture now closes the registered privileged mutation bypasses: 9/9 surfaces are network-evaluated and 0 known source bypasses remain. Production still requires coordinated secret provisioning, staged migration conformance, an OBSERVE window, a measured canary and service-only v4 activation.
Default mode=off; sourceBypassClosureReady=true; productionEnforceReady=false; production enforcement claimed=false.
MIRMC now contains a staged tenant-scoped retention control plane with bounded category policies, AAL2 administration, legal holds with creator/releaser separation and a service-only deletion-eligibility gate. Automatic deletion is off by default and no production purge is claimed.
Automatic deletion default=false; commercial records remain legal/contract-governed.
MIRMC now contains a staged tenant-scoped retention control plane with bounded category policies, AAL2 administration, legal holds with creator/releaser separation and a service-only deletion-eligibility gate. Automatic deletion is off by default and no production purge is claimed.
The source control plane is not a legal order or legal advice and production purge is not claimed.
MIRMC now maps eight code-backed processing activities to canonical provider boundaries, data classes, data subjects, retention categories and residency evidence states, and can build a procurement JSON packet from canonical registries. The map is engineering evidence only: no DPA, legal role, transfer mechanism, residency guarantee or compliance certification is inferred from source.
MIRMC publishes a code-backed provider/integration register that distinguishes core runtime dependencies from conditional and optional services. It deliberately does not pretend to be a signed legal subprocessor schedule or data-residency guarantee.
This engineering register is not a legal subprocessor schedule or data-residency guarantee. Actual provider use depends on enabled features and deployment configuration; contractual privacy terms must be reviewed separately.
Repository evidence
src/lib/enterprise-provider-register.ts
src/lib/enterprise-provider-register.test.ts
src/routes/$lang.providers.tsx
src/data/runtime-env-inventory.generated.ts
privacy · data-residency
Does MIRMC guarantee a specific customer data residency?
Not claimed
No. Repository evidence records provider and architectural boundaries but does not establish a contractual residency guarantee.
dataResidencyGuaranteed=false
Repository evidence
src/lib/enterprise-data-processing-map.ts
public/.well-known/mirmc-data-processing.json
compliance · dpa
Does this repository prove an executed DPA?
Not claimed
No. The engineering evidence map and provider inventory are procurement inputs, not an executed DPA or legal subprocessor schedule.
Repository evidence
src/lib/enterprise-data-processing-map.ts
src/lib/enterprise-procurement-evidence.ts
compliance · soc2
Is MIRMC SOC 2 certified?
Not certified
MIRMC does not claim SOC 2 certification in this trust registry.
Are recurring disaster-recovery drills production-proven?
Planned / open
MIRMC now has explicit engineering RPO/RTO targets and an isolated restore-drill protocol, but this audit still does not claim completed recurring DR evidence or verified achievement of those targets.
Repository evidence
src/lib/enterprise-saas-readiness.ts
src/lib/enterprise-operational-resilience.ts
docs/ENTERPRISE_OPERATIONAL_STATUS_SLO_V1.md
docs/ENTERPRISE_DR_RESTORE_DRILL_V1.md
operations · sla
Is a contractual uptime SLA evidenced by this repository?
Planned / open
Live operational transparency now exists and an incident operating model is defined, but historical uptime, historical incident evidence and contractual uptime/remedy commitments are not yet claimed as complete.
Repository evidence
src/lib/enterprise-saas-readiness.ts
docs/ENTERPRISE_OPERATIONAL_STATUS_SLO_V1.md
docs/ENTERPRISE_INCIDENT_OPERATIONS_V1.md
operations · release-authority
Is production release authority evidence-based and Cloudflare-bound?
Controlled / staged
Cloudflare candidate identity and fresh runtime probes are the production evidence boundary. A missing or failed hosted check is never silently converted into success.
Repository evidence
docs/ENTERPRISE_RELEASE_AUTHORITY_V1.md
src/data/cloudflare-candidate.generated.ts
README.md
operations · fleet
Does Agency provide multi-site fleet visibility?
Controlled / staged
Agency Overview now contains a staged aggregate-only multi-site operations surface for repository coverage, autonomy, preview approvals, domains and publication governance. The snapshot is tenant-authorized and does not expose raw customer/project rows.
Is main branch protection verified by repository settings?
Planned / open
The August 25, 2026 audit found main unprotected and without required status checks. CODEOWNERS and a staged ruleset policy are now prepared, but GitHub settings must enforce them before this control becomes implemented.
Does the browser grant commercial subscription state?
Controlled / staged
No browser-side plan grant. Stripe redirects do not grant a plan. Signed webhooks, server-owned price mappings and exact approved transitions are required before subscription state converges.
