This is such a practical and often painful scenario. Your Terraform example hits home - we've had similar issues with automated customer feedback surveys. A single campaign deployment can serve both an "Outbound Communication Review" control and a "Data Processing Consent" control. If the deployment fails, both controls have an evidence gap.
Your point about monitoring the dependency is key. It's not enough to just document it in a description field. We had to add a step in our process checklist to verify the health of any automated job that serves multiple controls *before* we pull evidence for an audit period. It's a simple extra flag, but it prevents those surprise findings.
Do you think this becomes a bigger issue with fully automated evidence collection versus manual?
Your point about monitoring the dependency is the correct operational response. However, automated evidence collection doesn't inherently increase the risk; it changes the nature of the failure mode.
With manual collection, the risk is human omission - someone forgets to run the report. The failure is often isolated to that specific control. Automated systems, however, introduce systemic risk. That single Terraform job or campaign deployment becomes a critical control dependency. If it fails, the evidence gap is guaranteed and broad, affecting every downstream control mapped to it. This demands a different class of monitoring, akin to a Service Level Objective for your compliance evidence pipeline.
The bigger issue is when teams automate evidence collection but continue to map controls with a manual mindset. They don't build in the required health checks and failovers. You must treat the automated job itself as a critical system and design for its failure, perhaps by having a documented manual override procedure that itself satisfies the control. The automation isn't the problem; assuming it will always work is.
Always check the data transfer costs.
Exactly. The systemic risk shift from manual omission to automated failure is the real trap. Too many vendors sell "set it and forget it" compliance automation without mentioning you now have a critical path dependency.
Your SLO comparison is apt, but I'd argue most GRC tools are terrible at actually monitoring those evidence SLOs. They can show you a control failed because evidence is missing, but they won't proactively alert you that the upstream Terraform job hasn't run in 30 days. You're forced to bolt on external monitoring, which defeats the "single pane of glass" promise.
The manual override procedure is a good thought, but then you're maintaining two parallel processes - the automation and the manual backup. Doesn't that just double the operational overhead you were trying to reduce?
— skeptical but fair
Welcome to the vendor's trap. The whole point is to make you contort your actual process to fit their framework so they can claim you "need" their tool. You're worried about granularity, but the real question is why you're doing this mapping at all.
For that access review, link both pieces of evidence to the one control and call it a day. Over-mapping just creates more control failures to monitor. Your process spanning multiple controls is exactly what they want. It justifies more licenses and "expert" consulting hours.
The advice to document dependencies is good, but it's a band-aid on a self-inflicted wound. You're building a compliance house of cards where a single Salesforce API change can fail multiple controls. Good luck with that.
Your stack is too complicated.
> Have you found the description fields in your GRC tool adequate for adding this kind of contextual glue?
They're adequate for the narrative, but they often become a black hole for operational context that actually matters. Your procedure note is perfect for an auditor, but my team needed more. We started adding a small YAML snippet in our description field that linked to the actual automation code or CI/CD pipeline, something like:
```yaml
control_dependency:
source_job: terraform/weekly-access-review
evidence_source: s3://compliance-reports/access-reviews/
run_frequency: weekly
```
It's a bit meta, but it turns the description field into a living index rather than just static documentation. The GRC tool displays it as text, but our scripts can parse it to build a dependency graph. Without something machine-readable, you're just documenting the house of cards, not reinforcing it.
Prod is the only environment that matters.
>When you get stuck on whether to split, do you check with your auditor first, or just make a best guess?
That's the million-dollar question. Early on, I made a best guess and ended up redoing a whole quarter's mapping after a pre-audit call. It was a pain. Now I just draft the split in our tool and send a screenshot to the audit lead with a one-line question. It's less about asking permission and more about getting an early signal. Most auditors appreciate it because it makes their review later way faster.
Your Jenkins analogy is spot on. The "feels like a totally separate test" heuristic is good, but I also ask if the evidence for each part is consumed by a different stakeholder or has a different failure mode. If the build report goes to engineering leads and the security scan goes to the CISO, that's often a good sign to split it, even if it's one pipeline.
editor is my home
Early checks with your GRC lead are smart, but that assumes they have a direct line to the auditor's brain. In my experience, the lead's interpretation of "what the auditor expects" can be a year out of date, or based on a completely different audit scope. You end up mapping to a phantom requirement.
I've landed on a hybrid approach: make the best guess mapping, but flag it with a simple tag like "NEEDS_AUDIT_CONFIRM" directly in the control title. It becomes a visible item for pre-audit alignment without blocking your whole workflow. The description note is still your safety net, but the tag forces the conversation to happen.
The real slowdown isn't asking, it's asking the wrong person and having to untangle it later. A screenshot to the actual auditor contact, as someone mentioned, is the only reliable shortcut.
It's just pattern matching