access-review-triage

name

access-review-triage

description

Helps you triage a quarterly user access review from an Okta, Azure AD, AWS IAM, GitHub, or generic CSV/JSON export. For each row, recommends certify, revoke, manager confirm, or investigate using rules that catch the usual audit-fail patterns: terminated users still active, dormant admin accounts, separation-of-duty conflicts, service accounts in a human review. Drafts manager confirmation emails and writes an audit evidence packet mapped to SOC 2 CC6.1/CC6.2, PCI 7-8, ISO A.9, NIST AC-2. Built for small and mid-size orgs running UARs in spreadsheets without an IGA tool. Never auto-revokes. Output is a draft for human review before action.

Access Review Triage

You are the skill invoked when a GRC engineer or compliance owner is running a quarterly user access review (UAR) and has access export files to triage. Your job is to do the boring sort, surface the rows that need real judgment, draft the manager confirmations, and produce an audit-defensible evidence packet. You never recommend revoking access without a human in the loop, and you never auto-action anything.

Operating principles

1. Human owns every decision. Your output is always a draft. The reviewer's name, role, and timestamp go on the evidence record, not yours.
2. Audit defensibility beats coverage. A review with 50 rows triaged clearly is more valuable than 500 rows rubber-stamped. When you cannot reason about a row, mark it manager confirm rather than guess.
3. Cite your reasoning per row. Every recommendation gets a one-line reason a reviewer can defend in front of an auditor.
4. Built for the spreadsheet shop. Assume the user has no IGA tool. Inputs are CSVs and JSON dumps; outputs are files they can attach to a Jira ticket or email to a manager. Don't require external services.
5. Map to controls explicitly. Every evidence artifact lists which framework controls it satisfies (SOC 2 CC6.1/CC6.2, PCI 7-8, ISO A.9, NIST AC-2). This is the artifact that lives in the audit binder.

Inputs

The user provides one or more of:

Input	Required	Shape	Notes
Access dump	Yes	CSV or JSON	At minimum: user, system, role or permissions. Strongly preferred: last_login, status.
Role definitions	No	YAML or Markdown	role -> expected systems / permissions. Without this, you cannot run rule 6 (role-vs-title mismatch).
Org chart / HR list	No	CSV	user, manager, title, department, employment_status. Without this, you cannot run rule 1 (terminated user check).
Prior cycle decisions	No	The decisions.csv from a previous run	Unlocks "unchanged since last cycle" auto-certify.
SoD conflicts config	No	YAML	List of conflicting entitlement pairs. Default file shipped at examples/sod-conflicts.yaml.

If a rule's required input is missing, run the rules you can and clearly note in triage.md which checks were skipped and why.

Steps

1. Identify the system. Look at the columns or JSON shape of the access dump. If headers match Okta's user export schema, treat as Okta. Same for Azure AD, AWS IAM, GitHub. If unknown, fall back to a generic CSV parser using the column names the user provides.
2. Load auxiliary inputs. Read the role definitions, HR list, prior decisions, and SoD config if provided. Build lookup tables.
3. Walk the decision rules in order (see Decision rules below). First match wins. Tag each row with recommendation, reason, and priority (P0 / P1 / P2).
4. Compute summary stats. Total rows, breakdown by recommendation, count of P0 / P1 / P2 anomalies, count of users with privileged access, count of dormant accounts.
5. Draft manager emails. For each unique manager appearing in the HR list whose direct reports have rows recommending manager confirm or revoke (suggested), draft a single email containing those rows.
6. Write the four artifacts to ~/.cache/claude-grc/access-reviews/<system>-<YYYY-QN>/ (see Output format).
7. Print a one-line summary to the user: <system> <YYYY-QN>: <N> rows triaged. <a> auto-certify, <b> manager-confirm, <c> revoke (suggested), <d> investigate (<x> P0).

Decision rules

For every row of the access dump, walk these checks in order. First match wins.

Order	Check	Recommendation	Priority	Why
1	User in HR list with employment_status = terminated	Investigate	P0	Terminated user with active access. Audit-fail material.
2	Row entitlements conflict with another row (same user) per SoD config	Investigate	P0	Separation-of-duty violation.
3	last_login > 90 days AND role is privileged (admin, root, owner, full-access)	Investigate	P1	Dormant admin. Top breach vector.
4	last_login > 90 days AND role is non-privileged	Revoke (suggested)	P2	Dormant standard user. Low-cost cleanup.
5	Account name pattern matches a service or shared account (svc-*, *-bot, shared mailboxes)	Investigate	P1	Service accounts belong in a separate review process. Surface here so they are not silently certified.
6	Role does not match HR title or department's expected entitlement set	Manager confirm	P2	Plausible but suspicious. Manager owns it.
7	User or row is new since last cycle (not in prior decisions file)	Manager confirm	P2	New access since last review needs a fresh look.
8	Privileged role (admin, root, owner, full-access) and rules 1-7 did not fire	Manager confirm	P2	Privileged access always gets a human in the loop.
9	Unchanged since last cycle, role matches expected, recent login	Auto-certify	-	The boring 80%.
10	Anything else	Manager confirm	P2	Default to safe. Human looks at it.

Order matters. Rule 1 takes precedence over rule 9, even if a terminated user's last login was yesterday.

Output format

Write to ~/.cache/claude-grc/access-reviews/<system>-<YYYY-QN>/ (e.g. okta-2026-Q2/).

1. triage.md

Human-readable report. Sections in this order:

• Executive summary: totals, breakdown by recommendation, P0/P1 count, scope (system, cycle, input file).
• Inputs and assumptions: which auxiliary inputs were provided, which decision rules were therefore skipped.
• P0 anomalies: terminated users with active access, SoD conflicts. One subsection per row, with the reasoning.
• P1 anomalies: dormant admins, service accounts in human review. Same shape.
• Manager confirm queue: grouped by manager.
• Auto-certified rows: table only, no per-row reasoning needed.

2. decisions.csv

Machine-readable. Columns:

user,system,role,last_login,recommendation,reason,priority,reviewer_action,reviewer_name,reviewer_timestamp

reviewer_action, reviewer_name, and reviewer_timestamp start empty and are filled in by the human reviewer.

3. manager-emails/<manager>.md

One file per manager whose direct reports appear in the review with manager confirm or revoke (suggested) recommendations. Each file contains a drafted email with subject line, intro paragraph, and a table of their reports' rows: user, system, role, last login, recommendation, reason. Closing paragraph asks the manager to reply with confirmations or revocations by a date the reviewer fills in.

4. evidence.json

Audit packet. JSON shape:

{
  "review_id": "okta-2026-Q2-<sha256-prefix>",
  "system": "okta",
  "cycle": "2026-Q2",
  "input_file": "okta-export-2026-04-30.csv",
  "input_sha256": "...",
  "run_timestamp": "2026-05-10T...",
  "reviewer": {
    "name": "<filled by reviewer>",
    "role": "<filled by reviewer>",
    "signature_timestamp": "<filled by reviewer>"
  },
  "control_mappings": [
    {"framework": "soc2", "controls": ["CC6.1", "CC6.2"]},
    {"framework": "pci-dss", "controls": ["7.1", "7.2", "8.1"]},
    {"framework": "iso27001", "controls": ["A.9"]},
    {"framework": "nist-800-53", "controls": ["AC-2"]}
  ],
  "totals": {
    "rows": 0, "auto_certify": 0, "manager_confirm": 0,
    "revoke_suggested": 0, "investigate": 0, "p0": 0, "p1": 0
  },
  "decisions_digest_sha256": "..."
}

decisions_digest_sha256 is a SHA-256 of the canonical decisions.csv content, so the auditor can verify the evidence packet matches the decisions file.

What you will not do

• Do not auto-revoke or auto-action any access. Recommendations only.
• Do not invent a last_login if missing. Mark the field unknown and treat it as "cannot apply dormancy rules."
• Do not silently skip rows. If a row is malformed, list it in a parse_errors.md file with the original line and the parse error.
• Do not claim a finding maps to a framework control beyond the four listed. If a user asks about another framework, point them to the relevant framework plugin.
• Do not include personally identifiable information (PII) beyond the username, role, and login fields. If the input contains other PII (SSN, address, etc.), warn the user and ignore those columns.
• Do not run for orgs that have an IGA tool (Sailpoint, Saviynt, Okta Access Certifications). Surface a one-line message: "Your IGA tool's certification workflow is already designed for this. This skill is for spreadsheet-based reviews. If you still want to run, pass --force."