grcskills
Menu

Access review campaign prep

Use this skill when a periodic user access review is due, an auditor asked for access review evidence, or someone says "prepare the access review", "run the quarterly user recertification", "who still has admin", "check leavers still have access", "build the access review sheets for managers" or "our last review was a rubber stamp". Picks the systems in scope, builds account populations reconciled against HR, pre-flags leavers, orphans, shared and dormant accounts, assigns independent reviewers, defines the decisions to record, and plans the removal follow-up.

EvidenceISO 27001SOC 2HIPAAPCI DSS

Use this to prepare a review campaign before reviewers see anything. You get, in a new folder ./access-review-campaign-prep/: a short plan saying which systems are reviewed, by whom and by when, with a sign-off line per reviewer (campaign-plan.md); one spreadsheet per system, openable in Excel, listing every account with the risky ones flagged at the top, ready for the reviewer (populations/<system>.csv); and a follow-up spreadsheet that tracks whether each removal really happened (follow-up-tracker.csv). This skill drafts for a human to review and sign; this skill never marks a control effective. Reviewers decide on access; the agent only prepares and flags.

Inputs to gather

Read the system inventory, the access control policy (it states the cycle the company promised), the role or permission matrix if one exists, the results of the last review, and account exports the reader provides from the identity provider and from each system. Ask for an HR export of employees and contractors with start and end dates. Ask the reader, in one message: the review deadline, who owns each system, and which systems keep local accounts outside single sign-on.

Step 1: choose the systems

Include, at minimum: the identity provider itself, production infrastructure and cloud consoles, databases with customer data, source code and CI, finance and payroll, and any system that holds regulated data. Then add the systems outside single sign-on; leavers survive longest in local accounts nobody remembers. Split each system into privileged and standard access. Privileged access usually gets a shorter cycle than standard access; take the cycle from the company's own policy, and run a framework lookup where a framework sets one.

Step 2: build and reconcile populations

For each system, export every account with: account name, display name, role or permission level, created date, last login, and whether it is a person, a service or a shared account. Include non-human access in the same population: API keys, personal access tokens, OAuth grants to third-party apps, service principals and SSH keys, each with an owner and a last-used date. An unowned token is the leaver of a SaaS estate. Record the export time and the exact query or screen used, because the auditor will ask how you know the list was complete. Then match accounts to the HR list and pre-flag:

  • Leaver active: the person left, the account is enabled. Highest priority.
  • No match: no HR record; external, test, or forgotten.
  • Shared or generic: admin, support, test; who uses it, and why is it not personal?
  • Service account without owner: name an owner or plan its removal.
  • Dormant: no login for 90 days or the period the policy sets.
  • Above role: permission level higher than the role matrix allows.
  • Mover: role or team changed in HR since the last review; check the access against the new role, because movers keep the old team's rights.
  • Break-glass: emergency accounts are legitimate, but each use needs a recorded reason and the credential re-locked afterwards.

Step 3: assign reviewers

The reviewer is the person who knows whether the access is still needed: the line manager for standard access, the system owner for privileged access. Nobody reviews their own access, and an administrator does not approve other administrators' access alone. Keep each reviewer's list under about 150 lines and put flagged lines first; a 900-line sheet gets approved in two minutes without being read.

Step 4: define what a decision looks like

Each line gets keep, remove or change, the reviewer's role, the decision date and, for any flagged line kept, a one-line reason. Record who reviewed which list, so completeness can be shown per reviewer: campaign-plan.md gets one sign-off line per reviewer (list, date, keep, remove and change counts), so the auditor does not have to reconstruct it from emails. Prepare the reviewer instructions: what each flag means, the deadline, and what happens to lines not reviewed by the deadline (escalation to the reviewer's manager, not silent approval).

Step 5: plan the follow-up

Every remove or change decision needs a ticket, which the system owner raises, with a due date the policy sets. After that date, ask the reader or campaign owner to obtain a fresh export of the account list from the system owner and provide it, then compare: a decision recorded with the account still active is the most common access review exception auditors find. Track it in the follow-up spreadsheet (follow-up-tracker.csv): account, decision, ticket, removed (yes or no), re-export time. Write campaign-plan.md with scope, reviewers, timeline, flag counts per system and the re-export step. Keep the exports, decisions and re-exports for the retention period the company's document rules set; run a framework lookup if a regulation sets a longer one.

If the output folder exists, ask before overwriting and offer a new subfolder instead.

What good looks like

  • The population for each system is complete and reproducible: export time and query recorded, reconciled to HR, with every unmatched account explained.
  • Flagged lines are at the top of each reviewer's list. Reviews that start with the risky lines catch them.
  • The common mistake is a review that only covers the single sign-on application list, with every line approved. The tells: a 100 percent keep rate, a review completed in minutes, and leavers found later in a system outside single sign-on.
  • Removal is proven by a second export, not by the reviewer's decision alone.
  • Metrics are ready for management: accounts reviewed, percent flagged, removals, median days from decision to removal.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-access-review-campaign-prep

Rules

  • MUST record the export time and query for every population.
  • MUST route every flagged line to a reviewer who is not the account holder.
  • MUST write outputs only inside ./access-review-campaign-prep/ and ask before overwriting.
  • NEVER disable, remove or change an account; the system owner acts on the reviewer's decision.
  • NEVER record a decision on a reviewer's behalf or approve lines left unreviewed.
  • NEVER copy passwords, tokens, API keys or session data into any export or output file.
  • NEVER contact system owners or request exports yourself; the reader or campaign owner obtains them.