An access review implementation consultant is the engagement you buy when the audit window is real and the review is still a spreadsheet. The first campaign has to finish: entitlements extracted from the system the auditor will sample, a living owner on every row, a decision log, and a revoke that hits the API and proves the right is gone. A strategy deck that postpones the work to a future platform purchase does not answer the sample.
Rutagon runs that first campaign as a build. We are an Alaska team that ships the pipeline and leaves it with your engineers. We are not a GRC administrator, not a security operations center, and not a testing vendor. Your GRC stays the system of record. How an access governance consultant structures the work is the longer view. This piece is the scope of the first implementation.
The first campaign is one system, done
The system is the one in the sample or the one your control owner cannot export. Common starts: the identity provider's privileged roles, a Microsoft 365 estate, a custom application with no SCIM feed, or AWS Identity Center. We do not open twelve connectors in week one. A finished campaign on the painful system beats a partial extract of everything.
Scope is written down before the extract: which environment, which roles count as in-scope, and which principals are people versus automation. That memo is evidence. It also stops the campaign from growing every time someone remembers another SaaS tool.
The extract is an API read, not a screenshot. Periodic review of accounts is the control NIST publishes in SP 800-53 Rev. 5. The campaign is how you produce evidence for the control you already named. Rows that the product's built-in review cannot see, such as shared mailbox ACEs in a shared mailbox access review, are still in scope if the auditor can reach that data. We would rather have a smaller system description than a campaign that pretends those ACEs are out of scope.
What an access review implementation consultant delivers
Four artifacts, in order.
The extract. Entitlements as data: principal, right, system, and whether the account is enabled. For groups, the effective path when nesting changes the answer. For privileged roles, eligibility as well as activation. The file is reproducible. Someone else can run the job and get the same population.
The owner map. Every row has a human owner who is enabled and who understands the right. Rows without an owner form a worklist, not an approve pile. We do not assign the compliance manager as owner of every row to make the sheet look complete. Owner repair is visible work. It is often the longest part, and it is the part tools skip.
The decision log. Approve or revoke, the reviewer's identity, and the time. Stored in the GRC you already run, or written there if the review happened in a workshop because the GRC could not host that system. The log is the recertification evidence for continuous access review afterward. The first campaign creates the baseline the continuous job diffs against.
The revoke. Approved removals call the system API. We re-read the entitlement. The second read is attached to the decision. A ticket to an administrator "please remove" is a queue, and queues are how the sample finds the access still present. If the system has no API, the revoke is a scripted admin action we watch and re-read, and that limitation is written on the system memo so you are not surprised next quarter.
row: principal + right + system
owner: enabled human, or exception
decision: approve or revoke, actor, time
proof: second read after revoke
home: the GRC you already run
Handoff is the fifth thing, and it is not a slide. Your team gets the job, the owner-map source, and a short runbook for the delta. The next cycle should not require us to click. If it does, the implementation is not done. Retained help is available for the awkward connector. It is not required for the campaign to exist.
Who this is for, and who should hire instead
This fits a CTO or a compliance lead at a company that already has a GRC platform and a control called access review, and does not have an engineer who can spend the next cycle on extracts. A fractional security lead can sponsor it. The signer is usually the person who owns engineering budget, because the work is code and directory change, not policy editing.
Hire a full-time owner if access review is a permanent function across dozens of systems and you want that person in every incident. Engage a boutique when you need the first trustworthy campaign and the pipeline that repeats it, and you do not want a twelve-month tool migration before any row is decided. Those are different shapes. We will say so on a call if a hire is the better answer.
We will also say so if the gap is not implementation. If nobody has named in-scope systems, the campaign has nothing to extract. If the GRC project has not started, we can still keep a decision log, and you will want a home for it before the auditor arrives. We do not pretend to be the auditor.
Out of scope on this engagement: intrusion detection operations, a managed detection retainer, penetration testing, and taking over Entra or Okta as your administrators. We integrate with the directory and the GRC. Your admins keep the tenant. Security automation is the capability page for the build.
How the work actually runs
Week shape, not a ceremony. First we confirm the system and the owner of the control. Then we run the extract and sit with the people who recognize the rows, because the owner map dies in isolation. Decisions happen in a working session with the API revoke ready the same week, not in a meeting that schedules the revoke for later. Evidence is filed as decisions happen so the last day is not an upload panic.
Alaska is home base. The work is remote against your tenant and your cloud, with named access that expires at the end of the engagement. Standing admin in your IdP is not how we leave. Credentials we used are removed, and that removal is a line on the decision log if it touched an in-scope system.
You keep the runbook and the code. We do not host a proprietary review product you must rent to see your own entitlements. If a product you already own can host the human step, we connect the extract to it. If it cannot see the system, the extract still runs and the GRC still receives the file.
Frequently Asked Questions
What do you ship in the first campaign?
An API extract of one in-scope system, an owner on each row, a decision log in the GRC you already run, and revokes confirmed by a second read. Handoff includes the job and a short runbook so the next cycle is a diff your team can run.
Why not start with every application at once?
The sample is a specific system. Finishing that campaign creates a pattern for the next one. Opening every connector at once produces a partial spreadsheet and no revokes. The second system starts after the first has owners and proof.
What if a row has no obvious owner?
It stays on an owner-repair list. We do not stamp the compliance lead as owner to clear the cell. A decision without a living owner is not evidence you want in the sample. Repair is part of the engagement, and it is often the slowest part.
Do you replace our GRC or our identity team?
Decisions are filed in the GRC you already run, and your administrators keep the directory. We build the extract and the revoke, then remove our own access. We do not operate a security monitoring service or perform penetration tests.
When is a full-time hire the better move?
When access reviews are a standing job across many systems and you want that owner inside the company every week. The implementation engagement is the first finished campaign and the pipeline. We will say which one matches the conversation.
Book a technical call about the first campaign. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.