Aug 28 · first result Application Promotion Stage-Gate Framework — Final Governance Deliverable Sandbox → Testing → Live A criteria-driven governance model for internal productivity tools and department-level web applications handling non-sensitive to internal operational data. Promotion is earned through verifiable evidence, never elapsed time. No gate references a calendar date or "time served"; every criterion maps to an artifact a reviewer can inspect. The framework is platform-agnostic — criteria reference outcomes (coverage, revert time, thresholds, SLOs), not specific tools or deployment models. Lifecycle Overview Decision states (both gates): Approve · Approve-with-conditions · Return-to-previous-stage · Retire. Tiering posture: Proportionality scales the depth of review, never skips validation. Apps touching regulated, personal, or customer-facing data fall outside this framework and require a full security/compliance review before entering Testing at all. Stage Definitions Stage 1 — Sandbox (Experimentation) Free-form prototyping and feasibility testing Synthetic or clearly-labeled test data only; no production credentials, no systems of record No SLA, no support obligation, no user-facing exposure Disposable infrastructure — most sandbox apps are expected never to leave Stage 2 — Testing (Validation) Pilot-group user acceptance testing plus automated regression coverage of core paths Internal operational data at most, per the tiering posture Staging-grade infrastructure mirroring the target production configuration closely enough to surface integration, performance, and recovery issues Stage 3 — Live (Production) Real user exposure with a designated primary support owner Full observability stack active (metrics, logs, dashboards, alerting) Tested rollback capability (revert within one hour) and tested backup/restore (or signed stateless acceptance) Live status is conditional, not permanent (§6) Gate 1: Sandbox → Testing Entry criteria (into the gate review itself) App owner has declared intent to promote and completed the one-page readiness checklist A named technical lead and app owner exist The app deploys to the testing environment reproducibly (scripted or documented) Exit criteria (all must be Met or Waived-with-record) Dimension Criterion Functional Core user journeys identified and demonstrably working in sandbox; known defects cataloged with severity; core paths agreed with the product owner Security / compliance Data classification declared (non-sensitive or internal operational); no production credentials or live customer data used; basic access model sketched; secrets-management attestation — no hardcoded credentials, secrets externalized to a managed store Security testing (baseline) Automated dependency/CVE scan executed; all critical findings remediated or waived with security sign-off; scan results attached to the checklist Operational Named technical lead and app owner; reproducible deployment; basic logging exists Performance Informal smoke evidence that the app handles expected pilot-group load without obvious failure — no formal thresholds at this gate Architecture One-page architecture and data-flow summary: components, data stores, external integrations, blast radius if the app fails Compatibility Browser-compatibility statement: supported browsers/versions declared and smoke-tested for the pilot group Required evidence artifacts One-page readiness checklist (standard template) Architecture & data-flow summary (draft) Lightweight security/compliance review record (data classification confirmed) Dependency/CVE scan results Deployment script or documented procedure Approver and independence rule Technical Lead is the sole approver — subject to the independence rule: if the Technical Lead is a primary contributor to the app, a second qualified reviewer (e.g., another team's technical lead or an engineering lead) must co-approve. Security-relevant criteria always require security sign-off regardless of who approves. Exception / waiver protocol Return-to-sandbox: any unmet functional or operational criterion. The app stays in sandbox with a written gap list; re-review is on-demand, not scheduled. Retire: a viable and encouraged outcome — most sandbox apps should be retired rather than force-promoted. Retire triggers the decommissioning checklist (§7). Waivers: granted only by the technical lead, except security criteria, which require security sign-off. Written, condition-boxed (tied to a remediation milestone, not a date), recorded in the waiver register (§8). Gate 2: Testing → Live Entry criteria Pilot testing complete with sign-off records collected All Gate 1 conditions (if approved-with-conditions) remediated and verified Evidence package assembled by the app owner Exit criteria Dimension Criterion Functional Zero open critical/high-severity defects; ≥80% of core paths covered by automated regression tests, all passing; documented pilot tester sign-off Security / compliance Full security/compliance review completed for the app's data tier; access controls verified in the testing environment; no unremediated findings above the tier's tolerance; secrets-management attestation (no hardcoded credentials; rotation policy defined) Security testing (all apps) SAST and/or DAST executed proportionate to data tier; automated dependency/CVE scan with zero unremediated criticals; results attached. Non-sensitive apps receive a lighter-scope scan, not a skipped one. Internal-operational-data apps additionally receive a penetration-style review of authentication and data flows Data governance Retention policy declared (what data, retained how long, disposal method); rollback data-integrity plan documented — schema migrations must be forward-compatible or accompanied by documented manual reconciliation steps, because a code revert does not revert written records Reliability / DR Backup/restore tested (demonstrated restore to a recovery point), or a written, security-signed acceptance that the app is stateless/disposable; DR posture declared proportionate to the data tier Operational Primary support owner designated; automated error logging and alerting configured and verified; rollback runbook tested — demonstrated revert within one hour, including the data-integrity steps; incident-response runbook (severity levels, escalation path, on-call chain); common-operations runbook (restart, config change, known-issue triage); user-facing support documentation published Observability Metrics and dashboards live (error rate, latency, availability at minimum); SLOs declared with error budget (e.g., 99.5% availability, p95 latency target); alert routing defined (who is paged, escalation after non-response); log retention period declared Performance Load test at projected full-audience concurrency with explicit pass thresholds recorded in the test execution log. Recommended defaults: p95 latency ≤ 500 ms at projected peak concurrent users; error rate ≤ 1% sustained over a 15-minute load window; no resource saturation (CPU/memory < 80%) at 1.5× projected peak. Thresholds may be adjusted by the approvers but must be numeric and recorded Architecture Summary updated to as-tested state; integration points documented; failure modes and blast radius understood and formally accepted by the approvers Compatibility Accessibility conformance statement (e.g., WCAG 2.1 AA target or documented exceptions); browser compatibility verified across the supported set; API-consumer compatibility contract if the app exposes APIs (versioning/breaking-change policy) Pre-authorized rollback triggers — defined numerically at Gate 2 Agreed by both approvers before go-live and recorded in the rollback runbook: Any critical defect confirmed in production Any data-integrity alarm (corrupt or missing records, failed write consistency) Error rate > 5% over a rolling 10-minute window, or availability below the declared SLO for 15 consecutive minutes Any of these authorizes the support owner to execute the rollback plan without further approval. Required evidence artifacts One-page readiness checklist Test execution logs (results, coverage %, defect register, load-test results with thresholds) Architecture & data-flow summary (as-tested, final) Rollback runbook plus drill record showing a demonstrated revert, including data-integrity steps Backup/restore test record or signed stateless acceptance Pilot tester sign-off record Security/compliance review record; SAST/DAST and dependency-scan results Incident-response and operations runbooks; observability configuration evidence (dashboards, alert routing, SLOs) Data retention and disposal policy declaration Approvers and deadlock resolution Product Owner and Engineering Lead jointly (both must approve). Security/compliance sign-off recorded for apps handling internal operational data. QA/Ops verifies test logs, coverage, alerting configuration, and the rollback drill. Deadlock resolution: if the co-approvers cannot agree within one business cycle (defined as one complete recurring operational cycle of the organization — e.g., one full week of normal business operations), the disagreement escalates to next-level engineering leadership, who decide within one subsequent business cycle. The dissenting position is recorded in the decision record. Exception / waiver protocol Non-waivable criteria: critical-severity defects, rollback capability, and backup/restore (or signed stateless acceptance). No approver may waive these. Waivers: high-severity security findings outside the tier's tolerance may be waived only with security sign-off; performance thresholds may be waived by both approvers jointly with the load-test evidence attached. All waivers written, condition-boxed, recorded in the waiver register. Waiver lapse without remediation triggers automatic demotion review back to Testing. Return-to-testing: any unmet criterion; the app remains in testing with a written gap list. Governance Roles and Ownership Role Gate 1 Gate 2 Post-Live App Owner Declares intent; owns checklist Presents evidence package Maintains checklist currency Technical Lead Approver (subject to independence rule) Contributes engineering evidence Contributes to re-certification QA / Ops Advises on testability Verifies logs, coverage, load test, alerting, rollback drill Monitors SLO/error budget Security / Compliance Confirms data classification; signs off CVE waivers Sign-off for internal-data apps; verifies scan results Access review at re-certification Product / Business Owner Confirms core paths and pilot group Co-approver Confirms ongoing business need Engineering Lead Second reviewer if independence rule triggers Co-approver Convenes demotion and re-certification reviews (with Security for data-related lapses) Accountability rules: a waiver cannot be self-granted — it must be authorized at or above the level that owns the risk. Decision records (approvals, returns, waivers, demotions) are retained for a minimum of three years as the audit trail, stored with the app's governance record. Risk Waiver Register Format All waivers are recorded in a single register per application, each entry containing: Field Content Waiver ID Unique, referenced on the readiness checklist (e.g., WVR-<app>-<seq>) Criterion waived Exact scorecard row Risk accepted Description of the consequence if unremediated Authorizing approver Must be at or above the level owning the risk; security criteria require security sign-off Remediation condition A verifiable condition, not a date — e.g., "coverage reaches 80%," "CVE-XXXX patched" Status Open / Remediated / Lapsed Review owner Technical Lead (Gate 1 waivers) or Engineering Lead (Gate 2 waivers) A waiver that lapses without remediation triggers an automatic demotion review; the register is inspected at every re-certification. Post-Live Maintenance and Re-Certification Live is a conditional status, governed two ways: Continuous criteria (failure triggers a demotion review, convened by the Engineering Lead, with Security for data-related lapses): Alerting and observability remain active — sustained alerting failure triggers review Rollback capability remains current — the runbook is re-verified after any significant change, defined objectively as: schema change, new external integration, authentication/authorization change, dependency major-version bump, or any change to the data-retention policy Primary support owner remains designated and responsive — ownership gaps trigger review SLOs and error budgets remain tracked; sustained error-budget exhaustion triggers a demotion review Periodic re-certification — event-driven, with a condition-based fallback to prevent staleness. It is triggered by: Any significant change as defined above, or Closure of the third hypercare window since the last re-certification (each hypercare closure demonstrates the app has completed another full validated usage cycle), or Any governance-requested review. Re-certification covers: access review (current user/role list verified against need); security posture (fresh dependency/CVE scan with zero unremediated criticals); runbook currency (rollback and incident-response runbooks re-verified); data-retention compliance spot-check; and business-need confirmation by the product owner. Failure of any item initiates a demotion review back to Testing. Hypercare and success validation: every go-live opens a hypercare window defined by a condition, not a date. It closes when the app has operated through at least one full business cycle — for apps with recurring workloads, one complete cycle of all recurring workloads (e.g., all weekly jobs); for event-driven apps without recurring workloads, a declared usage-volume condition agreed at Gate 2 (e.g., a minimum count of distinct user sessions or transactions comparable to the pilot baseline). During hypercare, the support owner tracks declared success metrics (adoption/usage against the pilot baseline, ticket volume, SLO attainment) and records them in the decision record to validate the promotion decision against real outcomes. Retire / Decommissioning Criteria The Retire decision at either gate — or post-live — triggers a decommissioning checklist: Data archival or disposal per the app's declared retention policy, with disposal method recorded Credential and secret revocation (API keys, service accounts, OAuth grants) Integration cleanup (webhooks, scheduled jobs, downstream consumers notified) Dependency license cleanup where the app owned licensed components Decommission record filed with the governance audit trail Readiness Scorecard One scorecard per application, completed at each gate. Status values: Met / Partially Met / Not Met / Waived (waiver ID). Dimension Criterion Sandbox (baseline) Gate 1: → Testing Gate 2: → Live Evidence Functional Core paths defined — Required Required Checklist Core paths demonstrably work Informal Required Required (automated) Demo / test logs Automated regression coverage ≥80% of core paths — — Required Test execution log Zero critical/high defects open — Defects cataloged Required Defect register Pilot tester sign-off — — Required Sign-off record Security / Compliance Data classification declared Recommended Required Required Checklist No production credentials / live data in sandbox Required Required N/A (verified) Attestation Secrets management (no hardcoded credentials, rotation defined) — Attestation Required Attestation + config Access controls verified — Sketched Required Review record Security review completed — Lightweight Required (internal-data apps) Review record Security Testing Dependency/CVE scan, zero unremediated criticals — Required Required (all apps) Scan results SAST/DAST proportionate to data tier — — Required Test results Penetration review (internal-data apps) — — Required Review record Data Governance Retention policy declared — — Required Policy record Rollback data-integrity plan (forward-compatible migrations or documented steps) — — Required Runbook section Disposal method defined — — Required Policy record Reliability / DR Backup/restore tested, or signed stateless acceptance — — Required Restore test record DR posture declared proportionate to data tier — — Required Architecture summary Operational Named app owner + technical lead Required Required Required Checklist Reproducible deployment to target environment — Required Required Deploy script/doc Logging in place Basic Required Automated + alerting Config evidence Primary support owner designated — — Required Checklist Rollback runbook, revert ≤1 hour (tested, incl. data steps) — — Required (tested) Runbook + drill record Incident-response runbook + escalation path — — Required Runbook Common-operations runbook + user-facing docs — — Required Runbook / docs Observability Metrics + dashboards (error rate, latency, availability) — — Required Dashboard evidence SLOs declared with error budget — — Required SLO record Alert routing + on-call/escalation defined — — Required Config evidence Log retention period declared — — Required Config evidence Performance Handles pilot load — Informal smoke Verified Load evidence Load test at projected full-audience concurrency with numeric thresholds (p95 latency, error rate, resource headroom) — — Required Load-test log Architecture Architecture/data-flow summary — Draft As-tested, final Summary doc Blast radius understood — Required Required + accepted Summary doc Compatibility Browser compatibility across supported set — Declared + smoke-tested Verified Test evidence Accessibility conformance statement — — Required (or documented exceptions) Statement API-consumer compatibility contract (if APIs exposed) — — Required API docs Governance Readiness checklist completed — Required Required Checklist Waivers documented, authorized, in register — If any If any (non-critical only) Waiver register Gate approval recorded (retained ≥3 years) — Technical Lead (+ second reviewer if independence rule triggers) Product Owner + Engineering Lead (+ Security if applicable) Decision record Hypercare success metrics declared — — Required at go-live Decision record Design Principles Evidence over elapsed time — every criterion maps to a verifiable artifact; nothing advances on tenure. Proportionality scales depth, never skips validation — lighter-scope security testing for non-sensitive tools; full sign-off for internal operational data; no app reaches Live without technical security validation. Single-point accountability with independence — named approvers per gate; no self-granted waivers; second review when the approver built the app. Reversibility with data awareness — Live is conditional; rollback plans account for data integrity, not just code; pre-authorized triggers are numerically defined before go-live. Recovery, not just rollback — backup/restore or signed stateless acceptance is non-waivable; a one-hour code revert is not a disaster-recovery strategy. Platform-agnostic — criteria reference outcomes (coverage, revert time, thresholds, SLOs) rather than specific tools or deployment models. Adoption note: adopt the one-page readiness checklist and waiver register as the artifacts both gates consume, and run one pilot promotion through Gate 1 to calibrate the criteria — in particular the load-test thresholds and rollback-trigger numbers, which should be tuned to actual audience sizes before the framework becomes mandatory.