SOC 2 evidence for internal tools is the request that makes a clean GRC dashboard look unfinished. The IdP connector is green. AWS Config is green. Then the auditor names the admin panel engineers use to refund a charge, the support console that can impersonate a tenant, and the pipeline scheduler that can dump a production table. Those tools are in scope because they are production access. They rarely have a vendor connector.
Rutagon builds adapters that snapshot users, privileged actions, and change history from those tools and attach the artifacts to the GRC tests you already own. We do not hold a SOC 2 attestation. We make the sample boring.
Why Auditors Always Ask
Internal tools concentrate break-glass power. A support impersonation feature is standing privileged access. An admin panel with a shared admin@ login is a shared secret. A pipeline runner with a personal access token is a non-human identity hiding in a human UI.
The AICPA Trust Services Criteria CC6 family cares about logical access to the system. CC7 cares that you detect and respond to deviations. Internal tools sit on both. NIST SP 800-53 Rev. 5 AC-2 and AU-2 say the same thing in control language: know the accounts, generate the events (NIST SP 800-53 Rev. 5).
If the tool cannot produce a user list, the finding writes itself.
SOC 2 Evidence for Internal Tools: The Adapter Set
We usually ship three adapters, not thirty.
Admin panel. Snapshot of local users and roles, last login if the table has it, and a revoke or disable path. If the panel uses the IdP, we still snapshot local overrides — the "emergency local admin" is the one reviewers forget.
Support console. Who can impersonate, whether impersonation is logged, and whether those logs survive the observation period. Impersonation without an audit row is a CC7 conversation.
Data pipeline / scheduler. Who can run or edit jobs that touch production data, which credentials the job assumes, and whether those credentials are still standing keys.
def snapshot_admin_panel(db):
users = db.query(
"""
SELECT id, email, role, disabled, last_login_at
FROM users
WHERE role IN ('admin', 'support', 'billing')
"""
)
return {
"captured_at": utcnow().isoformat(),
"users": users,
"shared_inboxes": [u for u in users if u.email.startswith("admin@")],
}
The snapshot is sealed and linked from the custom test. The campaign to review those users can reuse user access review automation. The collection pattern is compliance automation for non-standard systems. Capability: security automation.
Impersonation and "God Mode" Logs
Support tools fail evidence in a specific way: the feature exists, the log does not, or the log is a debug line that rolls every seven days. We add an append-only action log (actor, tenant, reason, at) before we argue about the GRC field names. Retention follows the observation period plus a margin, same as your other audit logs.
We do not build a SIEM. We do not staff a SOC. We make the privileged action queryable.
Pipelines Auditors Pull Into the Sample
"Who can run the backfill?" is a CC6 question. "Did someone run it off-hours?" is CC7. The adapter lists job editors and the IAM role or secret the job uses. If the secret is a long-lived key, that ticket belongs to rotate long-lived AWS credentials — evidence and elimination are the same backlog.
On a production SaaS platform, the first auditor sample of internal tools is almost never the pretty customer app. It is the thing your on-call uses at 2 a.m. We write that URL into the system inventory on day one so it cannot hide behind "just an internal thing" when fieldwork starts.
What We Will Not Claim
We will not say the adapter makes you SOC 2 certified. We will not say Rutagon is certified. We will not dump customer payloads into the evidence bucket. We collect who/what/when, not the refunded charge body.
Shared inboxes deserve their own row. admin@, support@, and deploy@ as login identities fail every "unique user" story. We convert those to named humans plus a role, or we treat the shared inbox as a non-human identity with a named owner and a review cadence tighter than the quarterly human campaign. Leaving them as "the support login" is how impersonation happens without an actor you can name.
Local emergency accounts — the ones created when SSO was down — need a disable-by-default flag and an expiry. If the panel cannot expire them, the adapter flags any local user that is not in the IdP join. That join is the same correlation we use for automate access reviews. The tool is custom. The identity math should not be.
Change history on internal tools is the artifact auditors ask for after the user list. Who added a new admin role last quarter? Who changed a refund limit? If the panel has no audit table, we add a thin append-only log before we argue about GRC field names. Retention matches the observation period plus a margin. Debug logs that roll every seven days are not that table.
Export jobs from these tools — CSV dumps of customers, bulk invoice reruns — belong in the same privileged-action set as impersonation. The adapter lists who can start those jobs and whether the run is logged with an actor and a reason. An unlogged export is a CC6 and CC7 problem at once.
We also snapshot configuration, not only users: feature flags that unlock god-mode, IP allowlists left at 0.0.0.0/0, and "support mode" toggles that persist after an incident. Those rows go into the sealed artifact next to the user list so the reviewer is not attesting to a moving target.
Ask us what your GRC platform isn't covering →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Which internal tools are usually in a SOC 2 sample?
Anything that can read or change customer data, change access, or change production configuration. Admin, support impersonation, billing consoles, and pipeline schedulers are the usual four.
What if the tool is a no-code vendor admin?
It is still in scope if operators use it on production data. We treat it as odd SaaS: export users, store the artifact, automate if an API exists.
Do we need SSO on internal tools before evidence?
SSO helps provisioning. Evidence still needs a local snapshot of roles and privileged actions. Both, not one.
Can we exclude a tool if only two people use it?
Headcount is not a scoping rule. Blast radius is. Two people with impersonation is still impersonation.
Will this replace our GRC access module?
No. It feeds it. The GRC tool remains the auditor's door. The adapter is the truth from the tool they named.