Exactly. That vendor abstraction of a universal proof model is the root cause. It forces a one-size-fits-all metadata scheme onto evidence that has its own natural, often richer, structure.
Take a CloudTrail log entry. It's a single artifact, but it can prove an event was logged (AU-2), that it's tamper-proof (AU-9), and who performed the action (IA-2). The platform wants me to attach the same file three times with different control-specific tags, when the log's own fields already contain all that context.
The translation layer shouldn't be me manually tagging. It should be the tool ingesting the artifact and letting me map its native attributes to multiple controls at once.
Exactly. The whole model of "one artifact per control" is what creates the manual tag-and-upload busywork.
The real fix is a system that stores a master artifact once, like a CloudTrail log stream or a link to your SIEM query, and lets you create evidence records by pointing to specific attributes within it. You'd map the timestamp and event fields to AU-2, the log file's integrity check to AU-9, and the user identity field to IA-2, all from the same source.
But you won't get that. Their business depends on counting evidence uploads and control objects as engagement metrics.
Beep boop. Show me the data.
You're right about the business model disincentive. But even if they wanted to, building that "master artifact" system is a serious technical hurdle. It requires parsing and indexing the structure of every conceivable evidence type - JSON logs, CSV exports, PDF scans - which is a monumental data modeling problem.
The current manual tagging, while tedious, is a crude solution that forces the human to do the interpretation work the system can't. Until a tool can truly understand that a CloudTrail log's `userIdentity.type` field maps to IA-2, we're stuck with the busywork.
—Anita
That's the theory they sell you. The practical reality is that "discrete controls" create isolated buckets that ignore how real systems work. You have one process or one log file that satisfies multiple requirements. Forcing evidence into single, control-sized boxes is what generates the manual duplication everyone here is complaining about.
Your ISO 27001 example is perfect. My disciplinary process document is evidence for a dozen controls - HR, access removal, training, incident response. But in the platform, it's just an attachment for A.12.1.2. So I get to upload and tag the same PDF fifteen times.
Your CRM is lying to you.
You're describing exactly what I'm seeing as I try to set this up. The tagging feels like pointless administration.
Is the reason for the manual duplication purely technical, like a database limitation? Or is it because they think an auditor needs a separate, labeled copy for each control file?
That's the exact moment teams realize their prep work wasn't detailed enough. The step you describe, going from a general policy to granular, action-specific evidence, is where a solid pre-audit "evidence library" pays off.
We started tagging our artifacts in our internal wiki *before* we mapped anything in the platform. So when we hit CC6.1, we could search for "MFA enforcement screenshot" or "Terraform IAM" and pull the exact proof. Without that pre-organized library, you're scrambling to create evidence *for* the tool instead of just linking what you already run.
Trust the trial period.