Modern GRC platforms automate evidence collection beautifully for the SaaS layer — SSO logs, standard cloud provider APIs, well-documented third-party integrations. The evidence gap almost always shows up in the same place: internal tools, homegrown systems, and legacy infrastructure that predates the compliance program itself.
Why the Gap Exists
GRC platform connectors are built against the vendors with the largest customer overlap — the AWS, Okta, GitHub, and Google Workspace integrations get built first and maintained best. A company's own internal admin tool, a legacy on-prem database, or a proprietary system inherited through an acquisition will never get a native connector, because the vendor has no reason to build one for a system unique to your environment.
The manual workaround most teams fall into — someone screenshots a config screen every quarter and uploads it as evidence — technically satisfies an auditor in the short term but doesn't scale, breaks silently when the person who knew how to do it leaves, and provides weaker evidence quality than an automated pipeline.
Building an Evidence Pipeline for a Non-Standard System
The architecture is consistent regardless of the specific system: extract the relevant control state directly from the source of truth, normalize it into the format your GRC platform (or auditor) expects, and push it on a schedule rather than relying on someone remembering to do it manually.
def collect_internal_tool_evidence(system_config: dict) -> EvidencePackage:
"""
Extracts control-relevant state directly from an internal tool's
database or admin API, normalizes it, and packages it as
auditor-ready evidence with a timestamp and source attestation.
"""
raw_state = extract_control_state(system_config)
normalized = normalize_to_control_schema(raw_state, control_id=system_config["control_id"])
return EvidencePackage(
control_id=system_config["control_id"],
system=system_config["name"],
collected_at=datetime.utcnow(),
evidence=normalized,
source_query=system_config["extraction_method"],
)
For a GRC platform with an evidence-upload API (most modern platforms offer this), the pipeline pushes the packaged evidence directly, tagged to the correct control, on the same cadence the platform expects for continuous monitoring — turning what used to be a quarterly manual scramble into a scheduled, unattended job.
Common Non-Standard Systems We Build Evidence Pipelines For
- Homegrown internal admin tools with their own user/role database, where access control evidence needs direct database extraction
- On-prem or self-hosted infrastructure (an internal Jenkins instance, a self-managed database cluster) where change management and vulnerability evidence needs to be pulled from logs and configuration state directly rather than a cloud API
- Legacy systems inherited through acquisition that predate the current compliance program and often lack any documentation of their own control state
- Custom-built customer data platforms where data handling and encryption evidence needs to be demonstrated against the specific architecture, not a generic template
Multi-Framework Evidence Without Tripling the Work
Companies pursuing SOC 2 alongside ISO 27001 or HIPAA often assume each framework requires separately collected evidence. In practice, the underlying control state (access logs, encryption configuration, vulnerability scan results) is often identical — what differs is the mapping and presentation format each framework expects. Building the evidence pipeline once against the actual system state, then mapping that single evidence set to multiple framework control IDs, avoids the redundant collection effort multi-framework programs otherwise create.
Positioning This Correctly Against Your GRC Platform
This is never a "your GRC platform is bad" conversation — Vanta, Drata, and Secureframe are genuinely well-built for what they cover. The honest framing is that every GRC platform has an edge where its connector library stops, and that edge is exactly where custom, non-standard systems live for most real companies past a certain size or age. Building the bridge to feed clean evidence into the platform you already pay for is the value, not replacing it.
Frequently Asked Questions
How do we know which of our internal systems need this treatment?
Start from your control matrix — for each control (access management, change management, vulnerability management, etc.), identify which in-scope systems your current GRC platform's connectors already cover, and any system left without automated coverage is a candidate for a custom evidence pipeline.
Can this work for systems with no API at all?
Yes, if there's a database or log file to extract from directly — read-only, narrowly-scoped credentials against the underlying data store often work even when the application layer exposes no formal API.
Does building this change how our auditor evaluates the evidence?
Auditors generally respond well to automated, timestamped, consistently-formatted evidence regardless of source — the key is that the evidence clearly traces to the actual system state and shows a consistent, repeatable collection method rather than an ad hoc screenshot.
How often should evidence be collected for non-standard systems?
Match your GRC platform's continuous monitoring cadence where possible (often daily or weekly for automatable checks) — matching the cadence of your SaaS-covered systems keeps your overall evidence posture consistent rather than having certain systems reviewed far less frequently.
What happens when the non-standard system itself changes or is replaced?
The extraction logic needs updating to match the new system's data model, but the overall pipeline architecture (extract, normalize, push to GRC platform) stays the same — this is a maintenance cost worth budgeting for as part of any legacy system migration project.
Ask us what your GRC platform isn't covering → rutagon.com/contact or call 907-841-8407.