The Minimum Security Bar

A team is ready to release an internal refund console. It sits behind company sign-in and a private network, so the launch feels modest. Then the final review finds that former support engineers remain in an access group, refund approvals are logged without the customer or amount, a deployment token has account-wide privileges, and nobody has restored the console’s database.

None of these gaps requires an exotic attacker. Together they make an ordinary mistake, stolen session, or failed database dangerous and hard to reconstruct. Calling the console internal does not change the customer data it reads or the money it can move.

The minimum security bar exists for this moment. It is the floor below which a system is not ready to handle real users, data, infrastructure, or business operations. A launch clears the bar only when another engineer can inspect the controls, follow their evidence, and reach the same conclusion.

Put every real system through the gate

Apply the bar to:

• Production services and jobs.
• Internal tools used with real business data.
• Development environments connected to production identity, data, secrets, or pipelines.
• Third-party services integrated into user, customer, operational, or regulated workflows.
• AI prototypes that process real customer, employee, financial, healthcare, credential, confidential, or regulated data.

Scope follows consequence, not labels. An AI prototype using synthetic records may remain outside the bar. The same prototype connected to the production identity provider and a customer-data index may not. A vendor’s certifications may support the evidence, but they do not answer who configured the integration, which data crosses it, or how access is removed.

The controlling rule is simple: a system may enter production only when its ownership, access, data protection, exposure, implementation, infrastructure, delivery path, detection, recovery, and evidence are inspectable. A requirement is either satisfied or covered by an explicit, time-bounded exception. Silence is a failed gate.

Begin with authority and data

The refund console first needs named engineering and operational owners, a security contact, an on-call or escalation path, and a data owner where classification or retention requires one. A team alias helps route questions; it does not replace the person or role accountable for the launch and the person responsible after launch.

Identity failures turn small weaknesses into broad compromise. At minimum:

• Production human access uses named accounts.
• Privileged access requires MFA. Prefer phishing-resistant MFA for high-impact roles.
• Shared production accounts are prohibited except controlled break-glass accounts with limited access, logging, storage controls, and drill records.
• Access is scoped to job function and reviewed on a defined cadence and after departures or role changes.
• Workloads use managed workload identity or short-lived credentials, not copied long-lived secrets.
• Administrative actions record the actor, delegated identity when present, target, action, decision, source, and correlation ID. Record a reason when the workflow requires one.

The launch reviewer should be able to answer, from current evidence, whether a departed engineer, stolen CI token, compromised support account, or forgotten integration can still reach production. For the console, that means inspecting group membership and role policy, not accepting a screenshot of the sign-in page. Break-glass access needs limited privileges, protected credential storage, alerting on use, an expiry or reset procedure, and a drill record.

Next, classify the data before choosing controls. Confirm intentionally public data against its source of truth. Restrict customer-confidential and personal data, encrypt it in transit and at rest, minimize copies, and define retention and deletion. Store credentials only in approved secret systems, rotate them, and never write them to logs. Treat financial or healthcare data as high-impact unless the data owner establishes otherwise. Classify security telemetry, AI prompts, outputs, training data, and evaluations by what they contain and what downstream systems can do with them.

The evidence should identify data flows, storage locations, access paths, retention, and any deletion or export obligations. For the refund console, “customer data” is too vague: the reviewer needs to see which identifiers and payment records enter the console, whether exports exist, where audit events go, and when each copy expires.

Trace the paths into production

Security at the network, application, and infrastructure layers must be inspected separately because each catches a different failure.

At the network layer, inventory every public endpoint and isolate administrative interfaces. Require TLS, filter ingress to intended sources and protocols, and find forgotten staging hosts, debug routes, permissive security groups, and public storage. “Behind the VPN” describes one exposure control; it does not replace identity, authorization, logging, patching, or recovery.

At the application layer, require authentication and server-side authorization for actions and objects. Validate input at trust boundaries, return errors that are useful without exposing secrets or internals, log security-relevant decisions, and scan dependencies. The refund console must reject a support agent who changes a customer identifier in a request or attempts a refund above their authority, even if the user interface never offers those choices. Negative authorization tests are evidence; a successful happy-path demo is not.

At the infrastructure layer, manage configuration as a reviewable source of truth, keep secrets in an approved secrets manager, scan and patch hosts, images, and managed services, and back up critical state. The inventory must include runtime components and dependencies, not just packages declared in the application repository. A secure application on an abandoned base image or an unmanaged database snapshot has not cleared the bar.

Treat delivery as production access

The delivery path can alter production and therefore belongs inside the gate. At minimum it requires:

• Protected main branch and required review.
• Required tests for security-critical paths.
• Dependency and container scanning appropriate to the runtime.
• No long-lived cloud or production secrets stored directly in pipeline variables unless a formal exception exists.
• Deploy identity is scoped to the target environment and action.
• Critical release artifacts have provenance or another verifiable build record.
• Emergency deploys leave evidence and post-action review.

The reviewer should trace one change from pull request to running artifact and ask where a compromised package, pipeline job, contributor token, or deployment key could alter it without review or traceability. Repository settings, pipeline policy, artifact records, cloud identity policy, and deployment events should answer that question together.

Make failure visible and recoverable

A generic logging checkbox does not show whether the team can recognize harm. Identify the system’s critical actions and failure paths, then log and alert on the ones that require a response. The baseline includes:

• Authentication and privileged access failures.
• Authorization denials for critical actions.
• Admin role changes.
• Secret creation, access, and rotation failures.
• Data export, bulk read, destructive action, and retention policy changes.
• Public exposure changes.
• Security control disablement.
• Backup and restore failures.

Every alert needs an owner, a first response action, and a route to the incident contact. An alert with no responder merely records a delayed incident. For each critical system, keep a logging and alerting plan that names the event source, expected signal, owner, runbook, retention, and a way to prove the route still works.

Recovery needs the same realism. A stateless service must be rebuildable and redeployable from managed configuration. A stateful internal tool needs a known backup location, restore procedure, owner, and a sample restore when business impact warrants it. A customer-facing stateful service needs a restore test, integrity verification, a customer-impact owner, and recovery-point and recovery-time targets where needed. A high-impact system also needs its dependency and access paths exercised and its recovery evidence retained.

Backups are inputs to recovery, not proof of it. The refund console remains blocked if nobody can restore its critical state with the permissions and configuration available during an incident. A successful test ends with trusted data and a usable service, not with a backup job reporting green.

Assemble evidence another engineer can follow

Evidence should come from normal engineering work and identify the system, environment, control, result, and time. Prefer durable links to authoritative records over copied screenshots. A scan result without its policy and disposition is incomplete; an architecture diagram that predates a new public endpoint may be worse than no diagram because it invites false confidence.

Keep a small system profile as the index. A practical evidence location can follow this shape:

security-evidence/
  system-profile.md
  architecture-and-data-flows/
  identity-and-access/
  application-and-infrastructure/
  delivery-and-dependencies/
  logging-and-response/
  recovery/
  exceptions/
  release-decisions/

The folders may be repository paths, service-catalog records, release-ticket links, or governed evidence-system locations. Do not duplicate secrets, personal data, tokens, or unrestricted logs into them. system-profile.md should link to the authoritative artifacts and name their owners and freshness expectations.

Before launch, the evidence set must contain or link to:

• Named engineering and operational owners, a security contact, and the incident escalation path.
• A system description, architecture diagram, assurance level, and—when the organization’s Level 2 or Level 3 policy requires it—a current threat model.
• Data classification, data-flow diagram, storage locations, and retention and deletion rules.
• Human roles, workload identities, authorization boundaries, privileged paths, access-review evidence, and break-glass design.
• Public and administrative endpoint inventory, network restrictions, and TLS status.
• Secrets inventory and rotation procedure; managed-configuration and runtime inventory.
• Dependency inventory, scanning results and dispositions, and a vulnerability-remediation owner and service-level target.
• Security-critical test results, protected-branch and review settings, build record, deploy identity, and deployment trace.
• Security events, alert routes, response owner, runbook, and a sample showing that critical actions can be reconstructed.
• Backup scope, restore procedure, last successful test, integrity result, and recovery targets where needed.
• The release decision and every open exception.

Record one defensible launch decision

Use one short production-readiness record to gather the decision without turning the form into a second source of truth:

System and environment:
Engineering owner / operational owner / security contact:
Assurance level and reason:
Data classes and authoritative data-flow link:
Public endpoints / administrative endpoints / restrictions:
Human roles / workload identities / privileged and break-glass paths:
Critical actions and required authorization tests:
Security events / alerts / owner / runbook:
Backup scope / restore test / recovery targets:
Vulnerability owner / remediation target:
Open exceptions and evidence links:
Decision / decision owner / time:

An exception is a decision, not an empty checkbox. It names the unmet requirement and failure mode, affected system and data, accountable risk owner, remediation owner and date, compensating control, detection and response plan, expiration, and reapproval rule. Evidence must show that the compensating control exists. Chapter 4 defines who may make that decision; a delivery team cannot grant itself authority by writing a ticket.

Return to the refund console. Stale support access blocks the identity requirement. Incomplete audit events block the ability to investigate critical actions. The broad deployment identity blocks the delivery requirement. The missing restore test blocks recovery readiness. The launch moves only when those gaps are fixed or when an authorized, time-bounded exception provides a credible alternate control. Schedule pressure changes neither the evidence nor the consequence.

The final gate can be read without a security specialist:

• If ownership is missing, do not launch.
• If data classification is unknown, do not launch with real data.
• If production access uses shared accounts, do not launch unless it is a controlled break-glass path.
• If public and administrative exposure is not inventoried, do not launch.
• If sensitive or multi-tenant actions lack object- and action-level authorization tests, do not launch.
• If critical state lacks a tested recovery path, do not claim recovery readiness.
• If a control has no current, discoverable evidence, treat it as unverified.
• If an exception lacks authority, an owner, a compensating control, detection, expiration, and a remediation path, it is unmanaged risk.

The bar does not promise that the system is secure. It makes the launch claim inspectable: these are the risks we considered, these controls are operating, this evidence supports them, and these named people own what remains.