Background

This document describes the access Masterpoint requests from clients, why we request it, and what happens when access is delayed or incomplete. It applies to IaC Audits and to implementation engagements such as migrations and platform builds.

The requests are split into two tiers. Tier 1 is read-only and applies to audits and discovery. Tier 2 is additive and applies when our engineers write and ship code. We will tell you which tiers your engagement needs.

Our security practices are documented in Masterpoint Security & Device Operations Standards.

Tier 1: Discovery and Audit access

Applies to IaC Audits and the discovery phase of any engagement. Everything here is read-only.

System Required Why we need it Examples
Your code Required Anywhere you keep infrastructure or DevOps code GitHub, GitLab, Bitbucket
Your cloud Required Calculating how much infrastructure is managed through IaC and how much is not AWS, GCP, Azure, Civo
Your documentation Required Understanding your architecture, culture, and processes Confluence, Notion, Google Drive
Your IaC CI/CD Required if in use Seeing how infrastructure changes actually ship Spacelift, Terraform Cloud, GitHub Actions, Jenkins
Your networking Optional How infrastructure connects to internal resources like databases Tailscale, StrongDM, OpenVPN
Your observability Optional Identifying which parts of your infrastructure are critical. We do not need log access Datadog, Honeycomb, New Relic, Grafana

For cloud access, share the account identifiers and a one-line description of each in our shared Slack channel, for example "AWS Account 123456789, development workloads." If other internal systems would give us useful context, add us to those too.

Tier 2: Implementation and Delivery access

Applies to migrations, platform builds, and any engagement where our engineers write and ship code. This is an additive request to the Tier 1 requests.

System Required Why we need it Examples
Repository write Required Pushing branches and opening PRs directly in the repos in scope GitHub, GitLab, Bitbucket
Your cloud, write Required Creating and modifying the infrastructure in scope. We will agree the specific permissions and accounts with your team AWS, GCP, Azure
IaC CI/CD write Required Creating and modifying stacks, workers, workflows, and policies, not just observing them Spacelift, Terraform Cloud, GitHub Actions
State backend Required Running plans and applies against the environments in scope locally, plus any locking mechanism S3 and DynamoDB, GCS, Terraform Cloud
Secrets, scoped Required Reading only the secrets the work requires AWS Secrets Manager, SSM Parameter Store, Vault
Identity provider Optional Sometimes provisioning our engineers through your existing SSO rather than standalone accounts is faster to grant, easier to audit, and immediate to revoke. This is something to discuss if you'd prefer a different option. Okta, AWS IAM Identity Center, Google Workspace, Entra ID

When access becomes a blocker

This section exists so both teams share a written understanding of what happens when access is incomplete. We understand the need to balance access and security, but we also need to be explicit about the ramifications of what can happen as a result.

Constrained or incrementally granted access does not slow an engagement proportionally. It slows it dramatically. In past engagements where access arrived in increments, work estimated at one day has taken a week.

What this means practically:

  1. For an IaC Audit, we require Tier 1 access no later than the Friday before the scheduled kickoff Monday. The audit runs a fixed one-week schedule, and access not landing prior to the audit week means that we'll need to push.
  2. For implementation engagements, access delays and constraints are typically where we see timeline revisions or change orders surface. We will raise it in writing as soon as we see it rather than absorbing the delay and delivering less.
  3. If something is genuinely not possible in your organization, tell us early. There is almost always an alternative. What does not work is finding out in a delay fashion where we lose too much time.

Who needs access

We will share the current list of Masterpoint team members needing access, with names and emails, by email or in our shared Slack channel. The list is kept to the engineers on your engagement. Please revoke all access when we finish.