An infrastructure services implementation checklist should prove that a platform can be operated, recovered and changed safely, not merely that resources were provisioned. Before work begins, translate the business service into owners, dependencies, service objectives, security requirements and recovery needs. The completed implementation should leave an evidence trail that another qualified operator can follow without relying on the original delivery team.
This checklist complements Edilec's infrastructure services delivery plan, infrastructure services FAQ, cloud infrastructure planning guide and managed infrastructure services guide. Use it as an acceptance framework and adapt control depth to the consequence of failure.
1. Define the service and accountable owners
Write a one-page service definition before choosing topology. State users, critical journeys, operating hours, data classes, upstream and downstream dependencies, expected demand, maintenance constraints and the person who accepts residual risk. Separate the service owner, technical owner, security owner and incident commander. One person may hold several roles in a small team, but the responsibilities must still be explicit and backed by alternates.
Choose a small set of user-relevant indicators. The Google SRE guidance on service level objectives distinguishes indicators, objectives and agreements and recommends measuring behavior users actually care about. For an internal order service, useful indicators might be successful requests, p95 latency, queue age and restore-point freshness. CPU utilization is diagnostic context, not a substitute for a service outcome.
| Acceptance area | Evidence required | Named approver |
|---|---|---|
| Service scope | Approved service definition and dependency map | Business service owner |
| Reliability | SLIs, targets, alert thresholds and escalation | Technical owner |
| Security | Data classification, access model and risk decisions | Security owner |
| Recovery | Restore test and recovery runbook | Continuity owner |
| Operations | Dashboards, change path and support rota | Operations lead |
2. Turn requirements into a build baseline
Create a traceable baseline for accounts, networks, compute, storage, identity, encryption, logging, backup, patching and time synchronization. The NIST SP 800-53 control catalog is intentionally flexible and customizable; use applicable control families to check coverage, not as a demand to implement every control. Record each selected requirement, its implementation, its evidence source and the person who owns exceptions.
Express repeatable infrastructure as reviewed code. Pin provider and module versions, require peer review, scan plans for policy violations and keep production credentials out of state files and build logs. Establish naming, tagging, region and account boundaries before the first deployment. Tags should identify owner, environment, service, data classification and cost center; reject resources that cannot be attributed or supported.
3. Establish identity, network and data boundaries
Begin with workforce and workload identity. Use federated sign-in, phishing-resistant multi-factor authentication where supported, short-lived administrative access and separate emergency credentials. Grant services narrowly scoped identities instead of shared keys. Review machine permissions independently from human permissions because an automated workload can make changes continuously and at machine speed.
Design network paths from required flows. Document source, destination, protocol, port, authentication and data sensitivity for every permitted connection. Private addressing is not proof of authorization. Apply egress controls, protected management paths and segmented failure domains. Encrypt sensitive data in transit and at rest, record key ownership and test rotation before go-live. Verify that backups inherit appropriate access and retention controls.
4. Make health and change observable
Instrument the service before production traffic arrives. The OpenTelemetry signals model separates traces, metrics, logs and baggage; choose the signal that answers each operating question. Collect request outcomes, latency distributions, saturation, dependency errors, deployment markers and security-relevant events. Redact secrets and personal data at collection time, and keep clock synchronization reliable enough to reconstruct an incident.
Every alert needs a condition, owner, severity, notification route and linked response. Page on urgent user impact or imminent objective loss; route capacity trends and certificate expiry to planned work. Test alert delivery outside business hours. Dashboards should pair service outcomes with likely causes so the responder can move from symptom to dependency without opening six disconnected tools.
5. Test recovery and failure behavior
Backups are inputs to recovery, not evidence of recoverability. Define recovery time and recovery point targets per service and validate them by restoring representative data into an isolated environment. The NIST contingency planning guide connects business impact analysis, recovery strategies, plans, testing and maintenance. Include identity, keys, network configuration, infrastructure code and external dependencies in the exercise.
| Failure test | Pass condition | Artifact |
|---|---|---|
| Single instance loss | Traffic continues or recovers within target | Test timeline and telemetry |
| Bad deployment | Previous version restored without data corruption | Rollback record |
| Credential compromise | Credential revoked and replacement propagated | Access and audit logs |
| Data deletion | Validated restore meets recovery point target | Restore report |
| Region or site loss | Documented degraded or failover mode works | Exercise report and actions |
Run at least one controlled failure that crosses team boundaries. A database failover that never tests application reconnection is incomplete. Capture detection time, decision time, execution time and user impact. Convert each unexpected manual step into a runbook improvement or automation task, with an owner and due date.
6. Control release, acceptance and handover
Use a staged release with a defined observation window, rollback trigger and change owner. Compare the deployed state with approved code, verify policy checks, run smoke tests from a user perspective and confirm monitoring receives real data. Freeze unrelated changes during the acceptance window. A successful provisioning command is only one checkpoint; the service is accepted after functional, security, resilience and support evidence is reviewed.
Handover should include architecture and data-flow diagrams, repositories, inventories, access procedures, supplier contacts, license and certificate renewals, dashboards, runbooks, backup schedules, known limitations and open risks. Have an operator who did not build the system execute a routine change and a recovery step. Their friction reveals undocumented assumptions quickly.
Govern the live service after launch
The NIST Cybersecurity Framework 2.0 adds Govern alongside Identify, Protect, Detect, Respond and Recover, reinforcing that infrastructure risk decisions need policy, accountability and oversight. Schedule access reviews, patch and vulnerability review, capacity review, restore tests, supplier review and objective review at frequencies tied to risk. Track drift between approved configuration and the live environment.
A practical first-month rhythm is daily review of failed automation and urgent alerts, weekly review of changes and capacity, and monthly review of access, cost, objectives and open risks. Do not reward low incident counts alone; under-reporting can look quiet. Examine near misses, recurring toil, stale runbooks and changes that required unusual intervention.
Worked example: accepting a customer portal platform
Consider a customer portal that reads account data, accepts service requests and sends notifications. The team defines successful sign-in and completed request submission as critical journeys, with a two-hour recovery target and fifteen-minute recovery-point target for submitted requests. The dependency map includes identity, application runtime, database, message queue, email provider, domain and encryption keys. The service owner accepts degraded email delivery as a temporary mode but not loss of a confirmed request.
The build baseline creates separate production and non-production accounts, federated workforce access, per-service identities, private database access, encrypted backups, central logs and policy-checked infrastructure code. Acceptance testing deploys a known artifact, submits synthetic requests, rotates a service credential and deliberately blocks the email provider. The portal continues accepting requests, marks notifications pending and alerts the correct owner. A database restore into isolation proves that request records meet the recovery point.
For handover, an operator who did not build the platform follows the runbook to grant temporary support access, deploy a patch, inspect the change marker, roll back and verify the service indicator. They then recover one deleted test request from backup. The team records actual timings, corrects two missing permissions and adds a queue-depth panel. Only after those actions are closed does the owner sign the acceptance record. This scenario tests service behavior, authority, evidence and operator understanding together.
Acceptance evidence to retain
- Approved service definition with users, data classes, dependencies and named risk owner.
- Reviewed infrastructure plan and deployed-state comparison for the accepted release.
- Identity and access test covering ordinary, privileged, service and emergency paths.
- Monitoring capture showing real requests, deployment markers and actionable alert delivery.
- Restore report with measured recovery point, recovery time and integrity checks.
- Failure exercise timeline showing detection, decision, containment, recovery and follow-up owners.
- Operator-led change and rollback record completed without the original builder's access.
- Handover index covering repositories, inventories, renewals, suppliers, runbooks and open risks.
Key takeaways
- Define service outcomes, dependencies and owners before selecting infrastructure.
- Treat infrastructure code, identity boundaries and evidence collection as parts of one baseline.
- Prove recovery with restores and cross-team failure exercises.
- Accept the service only after an independent operator can change and recover it.
- Keep governance, drift review and objective review active after launch.
Frequently asked questions
When is infrastructure ready for production?
It is ready when agreed service journeys work, controls are evidenced, telemetry and alerts are live, recovery has been demonstrated, rollback is practical, risks are accepted by named owners and the support team can operate it. Resource creation alone does not satisfy those conditions.
Should every service use the same checklist?
Use a common control skeleton, then scale depth by data sensitivity, external exposure, recovery needs and business consequence. A sandbox can use lighter evidence than a payment platform, but ownership, access, change and disposal should never be implicit.
How often should recovery be tested?
Set frequency from risk and rate of change. Test critical restore paths after material architecture changes and on a scheduled basis; exercise less critical systems often enough to keep procedures, credentials and operator knowledge current. Record measured results, not only attendance.
Conclusion
A dependable infrastructure implementation ends with verified capability, not a collection of deployed components. When requirements, controls, telemetry, recovery and handover share one evidence trail, the team can decide clearly whether the service is ready and improve it without rediscovering how it works.