The build-vs-buy question for access review automation gets asked backwards most of the time — as "should we buy a tool" rather than "what does our actual entitlement complexity require," which is the question that determines the right answer. A company with 15 SaaS applications, all SCIM-compatible, all behind a single IdP, has a fundamentally different decision than a company with the same headcount running a mix of standard SaaS, a homegrown internal admin panel, and a legacy on-prem system with local accounts.
The Three Categories Buyers Actually Fall Into
Stay manual, but structured. Companies under roughly 150 employees, on their first SOC 2 or ISO 27001 cycle, with a handful of systems in scope, often don't need automated tooling yet — a well-structured spreadsheet process with clear ownership and consistent evidence capture can satisfy a first audit. The mistake at this stage is buying enterprise tooling sized for a problem you don't have yet, not staying manual too long.
Buy a lightweight access-certification tool. Companies in the 150-1,000 employee range with a cloud/SaaS-heavy stack and trackable entitlement volume are the sweet spot for commercial access-certification products — the fastest path to real automation without enterprise IGA cost or implementation timeline. This is where most of the market (Lumos, Zluri, AccessOwl, Cakewalk, and similar) is built to serve.
Buy an enterprise IGA suite. Organizations with 1,000+ employees, hybrid on-prem/cloud environments, multiple overlapping frameworks (SOX plus SOC 2 plus ISO 27001), and M&A-driven entitlement sprawl are where role modeling and separation-of-duties enforcement at enterprise scale (SailPoint, Saviynt) earns its cost and implementation timeline.
The engineering-build option doesn't replace any of these categories cleanly — it fills the gap each of them leaves.
Where "Build" Actually Wins
Commercial access-certification and IGA tools are built to integrate with standard systems through documented connectors — Okta, Google Workspace, AWS IAM, common SaaS APIs. They stop, predictably, at internal applications with no SCIM support, homegrown admin panels, legacy systems with local user tables, and anything custom enough that a general-purpose connector was never going to cover it.
# custom_entitlement_adapter.py — exports entitlements from a homegrown admin panel
# in the normalized format an access-certification tool's API expects
import requests
def export_internal_app_entitlements(app_db_connection) -> list[dict]:
query = """
SELECT u.email, u.role, ap.permission_scope, ap.granted_at
FROM users u
JOIN app_permissions ap ON u.id = ap.user_id
WHERE u.active = true
"""
rows = app_db_connection.execute(query).fetchall()
return [
{
"identity": row["email"],
"system": "internal-admin-panel",
"entitlement": row["permission_scope"],
"granted_at": str(row["granted_at"]),
}
for row in rows
]
def push_to_certification_platform(entitlements: list[dict], api_token: str):
requests.post(
"https://api.access-cert-platform.example.com/v1/entitlements/import",
json={"entitlements": entitlements},
headers={"Authorization": f"Bearer {api_token}"},
)
This is the actual shape of "build vs buy" in most real access-governance programs — it isn't either/or, it's buying the certification workflow, evidence packaging, and reviewer UI (which are genuinely not worth rebuilding), and building the custom adapters that feed that platform data from systems its connector library never reached.
The Cost Comparison Nobody Runs Correctly
Comparing a commercial tool's license cost against "free, we'll build it ourselves" undercounts the build side badly — ongoing maintenance of custom connectors as source systems change their schemas or APIs is a real, recurring engineering cost, not a one-time build. Comparing a commercial tool's license cost against a one-time consulting engagement to build the custom-system adapters that feed into that tool is the more honest framing, because it correctly attributes the recurring workflow/UI/evidence-packaging cost to the platform (where it belongs) and the one-time integration engineering cost to the build (where it belongs).
Frequently Asked Questions
At what company size does buying an access-certification tool start to make sense?
Roughly 150 employees or 100+ applications in scope is a common inflection point — below that, the manual process cost is usually lower than a tool's implementation and license cost; above it, the manual process becomes error-prone and time-consuming enough that a tool pays for itself in saved reviewer hours alone.
Can we buy a tool and still need custom engineering work?
Yes, and this is the normal outcome for any company with even a handful of non-standard systems — the tool handles standard SaaS/IdP integrations well, and the remaining internal/custom/legacy systems need adapter work to feed data into the same certification workflow, which is exactly the gap a services engagement fills.
Is it ever right to build the entire access review system from scratch with no commercial tool at all?
Rarely, for the workflow and evidence-packaging layer — that's genuinely commoditized, well-solved software, and rebuilding it is a poor use of engineering time compared to buying it. The exception is companies with a very narrow, stable system list and spare platform engineering capacity where the specific combination makes a fully custom build genuinely cheaper over a multi-year horizon — this is uncommon, not the default case.
How do we know if our entitlement complexity is "trackable" versus needing enterprise IGA?
A rough signal: if a knowledgeable person can describe your organization's role-to-system-access mapping from memory in under ten minutes, you're likely in the lightweight-tool range. If the mapping requires cross-referencing multiple systems, historical exceptions, and several people's institutional knowledge to reconstruct, that complexity is a signal you're closer to needing enterprise IGA's role-modeling capability.
Does switching from manual to automated access reviews require re-doing prior review history?
No — the transition point is simply where future reviews are conducted going forward. Prior manual review evidence remains valid for the period it covers; there's no requirement to retroactively automate historical reviews, only to ensure the transition itself doesn't create a gap in coverage between the last manual review and the first automated one.
Rutagon builds the custom entitlement adapters that connect internal and legacy systems into whatever access-certification platform or workflow you're already running.
Talk to us about your access-review automation build → rutagon.com/contact | 907-841-8407 | contact@rutagon.com
Related reading: Access Review Software Alternative for Non-Standard Stacks · Access Reviews for Custom Applications · Security Automation Capability
External reference: NIST SP 800-53 Rev. 5 — Access Control Family