Automate access reviews is the search a Compliance Manager runs after the third quarter of CSV exports. The GRC tool already has a campaign module. The IGA catalog already talks to Microsoft 365 and Slack. The auditor still asked about the internal admin panel, the data warehouse roles, and the AWS permission sets that are not in the catalog. That is the build-vs-buy line. Buy covers the systems with a productized connector. Build covers the systems that pay your actual blast radius.
Rutagon builds those connectors and the revoke path behind them. We do not replace the IGA or GRC subscription. We do not publish a playbook for standing up a competing IGA company. We ship the 30 percent your current stack cannot see.
Where Buy Ends and a Connector Starts
SaaS IGA products earn their keep on SCIM apps and popular SaaS. They stall on:
- Homegrown admin UIs with a local user table
- Support tools that impersonate customers
- CI/CD orgs (GitHub, GitLab) with team inheritance
- Cloud IAM that is not the IdP (AWS Identity Center, standing IAM users)
- Data platforms whose roles are not groups in Okta
If more than two of those are in the last audit sample, you do not have an IGA gap. You have an engineering backlog.
Verizon's Data Breach Investigations Report has repeatedly treated stolen or abused credentials as a dominant breach pattern; the operational implication is dull: leftover access is not a paperwork issue (Verizon DBIR). Automating the review without automating the revoke leaves the credential in place.
Automate Access Reviews Without Buying Another UI
The decision we make with a CTO is not "which campaign product." It is "which systems get a first-class connector this quarter."
A first-class connector has four methods:
list_entitlements()— complete population, not a sampleget_effective_access(principal)— inheritance resolvedrevoke(principal, entitlement)— the write pathhealth()— so a failed pull fails the campaign instead of silently shrinking scope
Everything else — email nags, manager routing, auditor login — stays in the GRC tool.
class Connector(Protocol):
name: str
def list_entitlements(self) -> list[EntitlementRow]: ...
def effective_access(self, principal_id: str) -> list[EntitlementRow]: ...
def revoke(self, principal_id: str, entitlement_id: str) -> RevokeResult: ...
def health(self) -> Health: ...
def open_campaign(connectors: list[Connector], hris: HrisClient):
rows = []
for c in connectors:
assert c.health().ok, f"{c.name} unhealthy — abort campaign open"
rows.extend(c.list_entitlements())
return correlate(rows, hris.employment_status())
Aborting on health() is the unglamorous part. Teams that "automate" by swallowing connector errors produce campaigns that look complete and are not. Auditors eventually sample the missing system.
Build vs Buy, In Practice
Buy when the system is in the vendor catalog and the connector returns effective access, not just group names. Build when the catalog connector is a stub, when last-used is missing and you need CloudTrail or app logs to flag stale privilege, or when revoke requires a product-specific API the vendor will not write for your headcount.
A boutique build is usually a 30–90 day increment: inventory the sample list from the last audit, ship two or three connectors, wire evidence into the existing GRC custom tests, run one live campaign, then expand. That is the same delivery model as user access review automation and access review software alternative. Hiring shape is covered in hire a security automation engineer. The practice area is security automation.
We do not administer Okta, SailPoint, or your GRC tenant as a product. We integrate. If a catalog connector already works, we leave it alone.
Inheritance Is Why "Group Reviews" Lie
GitHub teams nest. AWS permission sets attach through Identity Center groups and can be shadowed by a standing IAM user. Internal apps copy "admin" from a department flag in the HRIS that nobody updates. A review of group names without effective access is how a contractor keeps production database rights through a parent team.
Every connector we keep in production resolves inheritance before the reviewer sees the row. That makes the campaign smaller and meaner: fewer rows, each one true.
What the Diagnostic Looks Like
An Access & Credential Governance Diagnostic is a short engagement, not a transformation program. We list in-scope systems from your last SOC 2 sample, mark each as catalog-covered or custom, and probe whether a revoke API exists. You leave with a connector backlog ordered by blast radius, not by vendor marketing.
Alaska-based delivery does not change the architecture. It does change who shows up on the call and writes the Terraform.
See what an Access & Credential Governance Diagnostic finds in your environment →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Can we automate access reviews only for AWS and leave SaaS to the GRC tool?
Yes. Hybrid campaigns are normal. The sealed evidence pack should say which systems were automated and which were catalog connectors so the auditor does not assume uniform coverage.
Do we need to replace our IGA product first?
No. Replacing IGA is a multi-year identity program. Custom connectors are a quarter. Start with the systems the last auditor actually sampled.
What if revoke has to be a ticket?
Then the campaign is not automated, and we should not tell the auditor it is. We will still snapshot and decide, and we will keep revoke items open until a human closes them with a proof screenshot or API stub. Honesty in scope beats a green dashboard.
How do custom connectors stay authenticated?
Workload identity or a short-lived app credential owned by a break-glass process — not a shared password in a wiki. See workload identity federation migration.
Is this a cheaper alternative to our GRC vendor?
No. It is the engineering layer behind the vendor you already bought. Price comparisons against GRC SaaS are the wrong buying frame for this work.