TIL: You can link a single piece of evidence to multiple controls.

Oh, that's a great tip. We do something similar when prepping for audits in our monitoring setup. A single dashboard screenshot can often serve as evidence for multiple controls related to alerting, uptime reporting, and change management.

Just a friendly warning: make sure the evidence description is general enough to cover all the controls you link it to. I've seen folks get tripped up because a note like "Proof of Q1 uptime for frontend" doesn't quite align with a control about *backend* service availability, even if it's the same dashboard.

What do you think is the trickiest part about mapping evidence? I still spend way too much time naming and tagging things.

That's such a handy feature! It reminds me of a time I was setting up automated evidence collection via webhooks for a similar framework. A single "deployment log" event from our CI/CD pipeline got tagged to controls for change management, separation of duties, *and* rollback procedures.

Your point about dragging from the library is key - I've seen folks try to re-upload and it creates a mess of duplicate files in the system.

One caveat I'd add: if you're using an API to push evidence into these platforms, check if the endpoint supports linking to multiple control IDs in one call. Sometimes the automation side isn't as flexible as the UI.

Great point about checking the API! I ran into that exact issue last month with Vanta's API. The documentation showed single-control linking, but their support team pointed me to a beta endpoint for multi-control attachments. Had to add an extra header to make it work.

Automated evidence from CI/CD pipelines is such a game-changer though. One successful SAST scan in our pipeline now feeds evidence for secure development, code review, *and* vulnerability management controls. It cuts our pre-audit scramble time in half.

Has anyone tried this with Drata's automation? Curious if their webhook structure is more flexible from the start.

That's the only sane way to do it. My favorite is a single "successful deployment" log covering change control, approvals, and rollback readiness. People re-uploading the same screenshot three times gives me hives.

Just watch your naming. "Bob's MFA screenshot.jpg" won't fly for three different controls. Go generic. "Infrastructure MFA enforcement evidence" works better.

Oh that's huge! I was literally just duplicating screenshots last week for our SOC2 stuff. I had no idea you could drag from the library like that. The UI really doesn't show it, you're right.

Can you give a quick example of how you'd name a piece of evidence so it makes sense for all the controls? Like, what would you call that AWS Config screenshot for MFA?

The naming strategy really depends on the scope of the controls. For your AWS Config MFA example, you need a name that abstracts away from the specific rule.

Instead of "Screenshot of IAM-001 rule compliance," I'd use something like "Evidence of MFA enforcement for all IAM users." That covers the technical control (MFA is on) and can also support an administrative control about policy enforcement. If you have a control about quarterly policy reviews, the same screenshot could work, but you'd need the name to reflect the period, like "Q2 2024 - MFA enforcement status for IAM users."

The key is to name the evidence for the underlying fact it proves, not the specific check you ran. That creates the necessary generality.

Wait until you see what happens when you need to *remove* that piece of evidence later because one control's context changed. Suddenly that "critical for efficiency" feature becomes a dependency nightmare where unpinning it from one control yanks it from three others. Been burned by that in Vanta.

The drag-and-drop is neat until you realize you've created a brittle web of evidence where a single generic description has to satisfy multiple auditors with different interpretations of scope. Good luck with that.

The example names above are already too long and specific. Your naming has to outlast your current audit cycle.

Think "Q3 Access Review Evidence," not "Screenshot of admin console 10-15-24.jpg." It's a balance - too generic and it's meaningless, too specific and it's useless for multiple controls.

And wait until you see the per-evidence storage costs some platforms charge after the first gig. One file linked to ten controls is still one file. Ten copies is ten files. Guess which one they'd prefer you upload.

You're right, the drag-and-drop from the evidence library isn't always intuitive. For your AWS Config MFA example, I'd build on what user978 said but shift the focus slightly.

I name that piece of evidence for the *policy outcome*, not the tool or rule. So it becomes "IAM Root and Privileged User MFA Enforcement." This works because it describes the compliant state you're proving, which can apply to several controls, like access management (CC6.1) and authentication safeguards (CC6.7).

The main caveat is ensuring the screenshot's date is either in the filename or clearly visible in the image, as it needs to be valid for the audit period for every control you link it to. A file named `2024-Q2_IAM-MFA-Enforcement.png` explicitly covers the temporal scope.

"Saves massive duplication" assumes your audit firm will accept it. Some won't. They'll argue each control needs evidence showing its specific context, even if it's the same file.

You might save time in upload, but you'll lose it arguing scope. Seen it happen.

Agreed on naming for the underlying fact. This is where automated billing evidence shines for multi control linking.

For example, an AWS Cost Explorer screenshot showing zero spend on a deprecated instance type can be named "Deprecated Instance Type Usage - Zero." That single artifact can prove compliance for a technical control (no deprecated resources), a financial control (cost avoidance), and an operational control (inventory management), as long as the date range in the screenshot is valid for all.

The risk, as others pointed out, is the audit firm's acceptance. We mitigate that by including a brief, generic description in the evidence notes that only states the objective fact ("Zero recorded usage of deprecated instance families G2 and I2 for Q2 2024"), leaving the control-specific interpretation to the auditor.