Checklist · Delivery

Before deploying a new service

The production-readiness gate for a new service, covering ownership, access, data, secrets and monitoring.

Owner: Service owner and engineering leadTime: 1 to 2 hoursISO 27001 A.8.25ISO 27001 A.8.29ISO 27001 A.8.31ISO 27001 A.8.32

0 of 27

Ownership and scope

A named service owner and an on-call team exist and have accepted the service.
The service is in the asset inventory with its data classification and business criticality.
An architecture diagram and data-flow diagram are current and reviewed by security.
Dependencies (databases, queues, third-party APIs) are listed with an owner for each.
A data protection assessment was done if the service handles personal data.

Code and supply chain

Source is in the organisation repository with branch protection and required review.
Dependency scan shows no unaddressed critical or high vulnerabilities.
Static analysis and secret scanning pass in CI; findings are fixed or formally accepted.
Container or build artifacts come from a trusted registry, are signed or pinned by digest, and have an SBOM.
A security test appropriate to the risk (pen test, DAST, threat model) has been completed and its findings triaged.

Identity and access

Users authenticate through the central identity provider with MFA; no local user database.
Roles follow least privilege; an access review owner and cadence are set.
Service-to-service credentials are individual to this service and rotate automatically or on a schedule.
Administrative access is separate from user access and goes through the privileged path.
Authorization is enforced on the server for every endpoint, not only hidden in the UI.

Secrets, data and network

No secrets in code, images or environment files in the repository; secrets come from the vault.
TLS everywhere, including internal hops; certificates are managed and monitored for expiry.
Data at rest encrypted; keys managed by the platform KMS with restricted use.
Network policy is default-deny; only the required ingress and egress are allowed.
Production data is not used in test environments, or is masked.
Rate limiting, request size limits and input validation are in place on public endpoints.

Operations

Health checks, metrics and alerts exist and have been fired once in a test.
Application and audit logs reach central logging without secrets or personal data in them.
Backups are configured, and a restore into a clean environment has been done.
Capacity and autoscaling limits are set; a load test confirms the target is met.
Runbook covers start/stop, common failures, rollback and who to page.
Rollback has been tested in staging, and the change is approved through the change process.

Adjust it to your environment before relying on it. A finished list shows a routine was followed; it does not guarantee nothing was missed. ISO references show where a list helps, not that it satisfies a control.

See these as tasks in Cisodium All checklists

Klar til å gå
forbi klassisk GRC?

14 dagers gratis prøve. Ikke noe kort. Nettskyen eller on-premises.

Bestill demo Snakk med salg →