Production access is the moment a teammate can change live infrastructure without a second pair of eyes. For a lean team of two to fifteen engineers, that moment is not a ceremony; it is a handoff of trust and blast radius. The conversation before first access should define what the person can touch, how they prove they are who they say they are, what they do when something breaks, and how the team will review the action afterward. This article lays out a repeatable pre-access conversation for AWS, GCP, or bare-metal environments where no dedicated SRE exists. It pairs with the team’s existing recovery checklist and access hygiene practices, and it assumes you already have a basic incident learning loop.

Why the First Access Conversation Is a Resilience Control

First access is not an onboarding formality. It is the point where a person’s mistakes can affect customer traffic, data durability, or the team’s ability to restore service. In lean teams, the person receiving access often has no prior experience with the specific production topology. They may know the codebase but not the Terraform state, the IAM boundary, or the backup schedule. A structured conversation reduces the chance that the first production action is also the first incident.

The conversation should produce three artifacts: a written scope of access, a named fallback contact, and a short list of “do not touch” systems. These artifacts are cheap to create and easy to review after an incident. They also make the access decision auditable without adding a heavyweight approval process.

What to Cover Before the First Credential Is Issued

The conversation works best as a 30-minute working session, not a lecture. The person receiving access should leave with a clear mental model of the production boundary and the team’s expectations. Below are the core topics, in the order that matches how a new operator will actually encounter the system.

1. The Production Boundary and Blast Radius

Start with a diagram or a shared terminal walkthrough of the production environment. Name the environments: production, staging, and any long-lived sandbox. For each, state what happens if someone deletes a resource, changes a security group, or rotates a secret incorrectly. On AWS, that means pointing to the specific VPC, account ID, and IAM role boundary. On GCP, it means naming the project and the service account scope. On bare metal, it means naming the hosts, the SSH jump path, and the backup target.

Ask the person to repeat back the blast radius in their own words. A useful prompt: “If you run this command in production, what is the worst thing that could happen, and how would we know?” This forces the person to connect the action to monitoring and alerting, not just to the CLI.

2. Authentication and Access Hygiene

Before issuing credentials, agree on the authentication method and the expected hygiene. For AWS, that usually means IAM Identity Center with short-lived credentials and MFA. For GCP, it means Workload Identity Federation or user accounts with MFA and conditional access. For bare metal, it means SSH keys with a passphrase and a named jump host. The conversation should state explicitly: no shared root accounts, no long-lived access keys stored in plaintext, and no password reuse across environments.

Also cover the offboarding path. If the person leaves the team, who revokes access and how quickly? A lean team can use a simple checklist: revoke IAM role, rotate shared secrets, remove SSH key, and confirm the person no longer appears in the cloud provider’s access logs. This is not a vendor-specific feature; it is a team habit.

3. The “Do Not Touch” List

Every production environment has systems that are fragile, expensive to rebuild, or outside the team’s normal operating envelope. Name them explicitly. Examples: the primary database, the object storage bucket holding backups, the DNS zone, the billing account, the CI/CD pipeline’s deploy credentials, and the monitoring stack itself. For each item, state why it is on the list and what to do instead if the person thinks they need to touch it.

The “do not touch” list is not a sign of distrust. It is a way to shrink the decision space during an incident. When a person is paged at 2 a.m., they should not be wondering whether they are allowed to restart the database. The list answers that question in advance.

4. The First Production Action

Do not let the first production action be an emergency. Choose a low-risk, reversible task: read logs, view a dashboard, run a read-only query, or deploy a canary to a staging-like path. The person should perform the action while a more experienced teammate watches. This is not pair programming for its own sake; it is a controlled way to verify that the person’s credentials work, their mental model matches reality, and they can find the relevant runbook.

After the action, ask two questions: “What did you expect to happen?” and “What did you observe?” The gap between expectation and observation is where most early mistakes hide. If the person cannot explain the gap, they are not ready for unsupervised access.

5. Incident Response and the Recovery Checklist

Before access is granted, the person should know where the incident response runbook lives and how to start it. For this site’s audience, that means the recovery checklist is already written and tested. The conversation should walk through the first three steps of that checklist, not the whole document. The goal is to confirm the person can find the checklist, understand the severity levels, and know who to call when they are unsure.

Also cover the “stop and call” threshold. Define the conditions under which the person should stop making changes and escalate: unknown error messages, unexpected data loss, a security alert, or any action that affects a paying customer. The threshold should be low enough that a new operator feels safe pausing, but high enough that they do not escalate every routine warning.

6. Post-Action Review and the Access Log

Agree on how the team will review production actions. For a lean team, a lightweight post-action review works better than a formal postmortem for every change. The rule can be simple: any production action that triggers an alert, requires a rollback, or touches the “do not touch” list gets a 15-minute written review within 24 hours. The review should answer three questions: what happened, what surprised us, and what should change in the runbook or the access boundary.

Keep an access log. It does not need to be a dedicated tool; a shared document or a Git-tracked file works. Record the date, the person, the scope of access, the fallback contact, and the date of the next review. This log becomes the evidence trail when the team later asks, “Who had access to the database in March?” It also makes the access decision reversible and reviewable.

What the Conversation Should Produce

By the end of the session, the team should have a short written record. It does not need to be a formal policy document. A half-page note in the team wiki or a Git-tracked markdown file is enough. The record should include:

• The person’s name and the date of first access.
• The exact scope: which environments, which services, which IAM roles or SSH keys.
• The named fallback contact for the first two weeks.
• The “do not touch” list, with a one-line reason for each item.
• The first production action the person will perform, and the expected result.
• The review cadence: when the team will revisit the access decision.

This record is the team’s memory. It prevents the common failure mode where a person receives broad access during an emergency, the emergency ends, and the access quietly remains. A quarterly review of the access log catches that drift.

Common Failure Patterns and How the Conversation Prevents Them

Lean teams tend to make the same access mistakes. The pre-access conversation is a cheap way to interrupt each one.

Access Creep After an Incident

During an outage, a teammate may be given temporary admin access to unblock a deploy. After the outage, nobody revokes it. The pre-access conversation sets the expectation that temporary access has an expiration date and a named owner. The access log makes the expiration visible.

The “Read-Only” Illusion

Teams often say a new person has “read-only” access, but the actual IAM policy or SSH key allows more. The conversation should include a quick review of the exact policy document or key permissions. On AWS, that means reading the IAM policy JSON aloud. On GCP, it means checking the role bindings. On bare metal, it means checking sudoers. The person receiving access should be able to state what they can and cannot do in one sentence.

The Missing Fallback Contact

A new operator hits an unfamiliar error at 11 p.m. and does not know who to call. They either guess and make things worse, or they do nothing and the incident grows. The pre-access conversation names a specific fallback contact and sets the expectation that calling is not a failure. The fallback contact should be someone who has production experience and is willing to answer questions for the first two weeks.

The Untested Recovery Path

Access is granted, but the person has never seen the backup restore process. When the first real incident happens, they discover the restore takes four hours, not forty minutes. The pre-access conversation should include a walkthrough of the recovery checklist, not just a link to it. If the team has not tested the restore recently, that is a separate gap to close before granting access.

How to Adapt the Conversation for Different Team Sizes

The core topics stay the same, but the format changes with team size.

Two to five engineers: The conversation is informal but still written down. The person receiving access is often a founder or an early engineer who already has broad context. The risk is not ignorance but overconfidence. The conversation should focus on the “do not touch” list and the fallback contact, because the team is too small to absorb a long outage.

Six to fifteen engineers: The conversation becomes a short checklist that a team lead or senior engineer runs. The access log moves into a shared document or a Git repo. The review cadence becomes quarterly. The “do not touch” list is maintained by the team, not by one person.

Bare-metal or hybrid teams: The conversation adds a hardware layer. The person needs to know which physical hosts are production, how to reach the out-of-band management interface, and what happens if a reboot does not come back. The fallback contact should include someone who can physically access the hardware if needed.

What to Do After the Conversation

The conversation is not the end of the access decision. It is the start of a short probation period. For the first two weeks, the person’s production actions should be visible to the fallback contact. That visibility can be as simple as a shared Slack channel where the person posts a one-line note before and after each production change. The note does not need approval; it needs visibility.

At the end of the probation period, the team reviews the access log and asks three questions: Did the person follow the expected hygiene? Did any action surprise the team? Is the access scope still correct? If the answers are yes, yes, and yes, the access becomes routine. If not, the team adjusts the scope or extends the probation.

Frequently Asked Questions

How long should the first access conversation take?

Thirty minutes is usually enough for a focused session. The goal is not to cover every possible failure mode. It is to establish the production boundary, the “do not touch” list, the fallback contact, and the first low-risk action. If the environment is unusually complex, split the conversation into two sessions: one for the boundary and access scope, one for the recovery checklist and incident response.

Should we use a formal access request form?

For a lean team, a formal form is often overkill. A half-page note in the team wiki or a Git-tracked markdown file is enough. The key is that the record exists and is reviewed. If the team grows beyond fifteen engineers or enters a compliance-sensitive industry, a lightweight form with the same fields can replace the note without changing the underlying process.

What if the person needs access during an emergency before the conversation happens?

Grant the minimum access needed to resolve the emergency, and schedule the full conversation within 24 hours. The emergency access should be time-bound and named in the access log. After the conversation, the team should review whether the emergency access was broader than necessary and revoke or narrow it. This is a common pattern in lean teams, and the access log is what makes it visible.

How often should we review existing production access?

Quarterly is a reasonable cadence for a team of two to fifteen engineers. The review does not need to be a meeting. A single person can pull the access log, check the current IAM roles or SSH keys, and flag any drift. The review should answer one question: does every person with production access still need it at the current scope? If the answer is no, narrow or revoke.

Next Step: Pair the Conversation with a Tested Recovery Path

The first access conversation is only as strong as the team’s ability to recover from a mistake. If the person receiving access has never seen a restore work, the conversation is incomplete. The natural next step is to run a short recovery drill with the new person as the operator. That drill should follow the team’s existing recovery checklist and produce a written note about what worked and what did not. Over time, these notes become the team’s own evidence base for what production access should look like.