`cis_extensions.access_approval` — version 1.1

Source: presets/cis/access-approval.satz

Purpose

CIS 4.0 §2.15 / 5.0 §2.16 — Access Approval: Google personnel reach the organisation's content only after someone approves the request.

Opt-in because it changes every support case: a Google engineer who needs to look at the customer's content waits until someone on the notification list approves. Who that is, is the customer's decision.

Access Approval needs Access Transparency enabled for the organisation first. Access Transparency has no provider resource: an organisation administrator switches it on in the Cloud console (IAM & Admin → Settings) before the apply that creates these settings, and the apply fails without it.

Deleting these settings switches Access Approval off for the organisation.

Use it

params {
  cis_access_approval = true

  // the pack's own defaults — copy only the lines you change
  access_approval_notification_emails = []
}

use "presets/cis/access-approval.satz" when cis_access_approval

cis_access_approval is the gate: while it is falsy the pack contributes nothing — no resources, no params, no claims. It is declared by CIS_GCP_Foundation_4_0, and the estate's own binding wins.

Needs from outside the pack:

customer_organization_id — declared by estate_core; use one of them alongside, or declare it in the estate.

Params

param	default
`access_approval_notification_emails`	`[]`

Questions

What to ask before this pack is configured, and what changing the answer costs.

asks about	prompt	reversal	blast	recommends
`access_approval_notification_emails`	Which addresses receive Google's access approval requests?	edit	low	—

access_approval_notification_emails — Every request by Google personnel to reach the organisation's content waits for an approval from this list. Nobody on it, or an unwatched mailbox, stalls support cases until someone answers.

Contributes

resource type	labels
`google_organization_access_approval_settings`	`access_approval`

Claims

framework	control	title	kind	witnesses	interpretation
cis-gcp 4.0	2.15	Access Approval enabled	implements	`google_organization_access_approval_settings.access_approval`	Access Approval covers every supported service at the organisation, so Google personnel reach its content only after an approval.
cis-gcp 5.0	2.16	Access Approval enabled	implements	`google_organization_access_approval_settings.access_approval`	As for 4.0 §2.15 (5.0 §2.16: its new §2.2 moved the rest of §2 by one).

What the controls ask (this project's paraphrase from the catalog — never the framework's own text):

Access Approval enabled (cis-gcp 4.0 §2.15, cis-gcp 5.0 §2.16) — Google personnel reach the organisation's content only after someone approves the request.

Manual duties (a control stays partial until each is attested):

answer-requests (cis-gcp 4.0 §2.15, cis-gcp 5.0 §2.16) — Someone on the notification list answers each request; an unanswered request is a support case that waits.

Every resource this pack contributes is a witness of a claim above.

History

version	date	change
1.1	2026-09-30	every claim states its measure without satz: `gcloud` (the commands that meet the control the way the claim's resources do), `gcloud_check` (the commands that show whether it is met) and `risk` (what goes wrong without it); `require` and `report-compliance` carry them in each control's `measures`. Nothing emitted changes
1.0	2026-09-11	CIS 4.0 2.15 / 5.0 2.16, opt-in: Access Approval at the organisation for every supported service; asks for the notification addresses (blocking until named). Needs Access Transparency, which has no provider resource

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

Access Transparency has no provider resource: an organisation administrator switches it on in the Cloud console, and this apply fails until they have. The notification address list has no default on purpose — an approval request nobody receives is worse than none.

cis_extensions.access_approval — version 1.1