Guide
Move to production safely
Expand monitoring with explicit scope, ownership, validation, and recovery responsibilities.
Last reviewed September 12, 2026
Move to production in stages. Installation, observation, notifications, and policy enforcement carry different operational risks and should not be introduced as one large change. This guide helps the team decide whether the observed coverage and support model are ready for expansion.
Assign accountable owners
Use the following table to understand how each area supports the task.
| Role | What that owner does |
|---|---|
| Security owner | Reviews exposure and findings, defines policy intent, and coordinates security escalation. |
| Web engineering owner | Deploys SiteWall, validates website behavior, explains loading, and performs recovery. |
| Service owner | Explains why an important provider is present and which journeys depend on it. |
| Compliance owner | Determines whether records support a requirement and preserves scope and provenance. |
| Project administrator | Maintains project access, configuration context, and administrative continuity. |
Review production readiness
- 1.
Confirm the production project
Use the project selector and verify the production project name, domain, environment, administrator, and intended scope.
- 2.
Review journey coverage
Compare the planned page and journey list with the sessions and records actually captured. Mark untested consent states, user states, regions, devices, and conditional features as gaps.
- 3.
Review important dependencies
In Providers, Inventory, and Exposure Map, identify the services and resources required by login, checkout, consent, payments, support, analytics, and other critical functions. Assign a service owner to each consequential dependency.
- 4.
Review open findings
In Issues and Anomalies, separate understood conditions from unresolved findings. Give every consequential open item an owner, next action, and target date.
- 5.
Confirm recovery
Verify who can disable SiteWall initialization, reverse a policy, or restore website behavior. The recovery method should be documented and tested before restrictive controls are introduced.
Production readiness checklist
Use the following table to understand how each area supports the task.
| Area | Ready when |
|---|---|
| Scope | The domain, included pages, journeys, states, and known gaps are documented. |
| Website safety | Loading order, CSP, consent, performance, and critical functionality were validated. |
| Observation | Website activity and matching SiteWall records were confirmed across the agreed journey set. |
| Findings | Issue and anomaly owners understand severity, escalation, and closure expectations. |
| Controls | Every planned policy has a reason, approver, affected scope, validation plan, and recovery action. |
| Evidence | Reviewers understand the project, journey, entity, and time boundaries of exported records. |
Make and execute the rollout decision
- 1.
Separate blockers from follow-ups
A blocker prevents safe expansion. An accepted follow-up has a named owner, due date, and documented reason it can remain open.
- 2.
Run the final journey set
Immediately before expansion, repeat the critical paths and confirm both website health and matching SiteWall observations.
- 3.
Record approval or pause
The deployment and operational owners should record the decision, included scope, accepted gaps, monitoring window, and recovery contact.
- 4.
Monitor the initial production window
Keep web engineering and security reviewers available. Review newly observed entities, issues, and anomalies promptly and compare them with known releases or traffic changes.
- 5.
Expand one dimension at a time
Add more pages or traffic before introducing notifications or policies. This makes unexpected behavior easier to attribute and reverse.