Am I the only one who finds the 'evidence requests' wording confusing to engineers?

Agreed, the semantic load is significant. We measured this indirectly by tracking ticket resolution time before and after renaming similar tasks in our Jira workflow.

Tickets with abstract compliance labels like "evidence request" took an average of 48 hours longer from assignment to start of work, compared to tickets with concrete engineering verbs like "configure," "document," or "validate." That initial confusion and context-seeking creates real delay.

Your "Proof of session management policy" example is spot on. In our system, we broke that down into two discrete tasks: "Apply 8-hour timeout in Okta rule" and "Attach screenshot of Okta rule to Confluence page." The work was the same, but the cognitive overhead for the engineer vanished.

Love that you measured it. The 48-hour lag feels very real. It's not just the confusion, it's that "I don't know what this is so I'll let it sit" inertia.

The concrete breakdown you landed on is perfect. It reminds me of the "job story" format we've used for user stories: "When a ticket says X, an engineer needs to do Y." It bridges that language gap by describing the actual action, not the auditor's classification.

One caveat we ran into was that splitting one "evidence request" into multiple engineering tasks sometimes broke the audit trail in the GRC tool. Did you have to build any extra links back to the original request, or did your compliance team adapt to the new structure?

That analogy with 'source artifact contribution request' is spot on! It really highlights how jargon can create unnecessary friction.

I'm new to this too, and I've seen similar issues where tool terms don't match how teams actually work. For instance, calling a simple status update a 'stakeholder sync' can make it seem more formal than it is.

How did your team approach renaming without causing confusion with the compliance folks? 😅

Spot on about that accusatory feeling. I felt the exact same thing when our tickets started coming through. My first thought was always, "Wait, what went wrong?" before even reading the description.

I wonder if part of the friction comes from mixing two different audiences in one term. It's built for the audit trail, not the action. So it's like getting a spec written for the QA person, not the developer.

Did you find that the confusion was mostly with senior engineers who've seen incident reports, or did the new hires get tripped up too?

You've hit on the core problem. This is just another layer of abstraction that sits between the work and the tool tracking it. The issue isn't just that the term is confusing, it's that the process is often detached from actual engineering artifacts.

The "proof of session management policy" request should be a pull request that changes a config file, a commit hash, or a link to a running system's admin panel. The evidence is a byproduct of the work, not a separate "request." When you treat it as the latter, you're begging engineers to generate compliance theater.

You're right to worry about the temporary adapter becoming permanent. We've seen that happen. In our case, the engineering lead built the initial mapping ("evidence request" = "create this PR"), but it only worked because a compliance person sat in on the planning. They owned translating the auditor-speak into actual tasks.

To keep automation prioritized, we tied it to a metric: manual evidence collection hours per sprint. Once that translation layer was built, the goal was to drive that number to zero. It became a shared KPI between the teams, which kept the pressure on to build the real integrations.

That shared KPI is such a smart move. It stops the translation work from becoming "just how we do things." We tried something similar but tracked "tickets requiring clarification" before work could start. Driving that down forced the conversation about root cause, which was the confusing language.

I'm curious, did you find that metric created any unintended pressure? Like, did teams ever cut corners on actual compliance to hit the zero manual hours target? We had to watch out for that a bit.

You're not wrong about the wording being terrible. But the real problem is treating compliance as a separate "request" at all.

If you need proof of a session timeout, that should be a pipeline that checks the actual IdP config and alerts if it's wrong. An "evidence request" is just a manual ticket for a process you haven't automated yet. The confusing term is a symptom.

We call them "control failures" in our Airflow DAG. No one misunderstands that. It either passes the check or it doesn't.

That analogy of "source artifact contribution request" made me laugh because it's painfully accurate. It's the same kind of unnecessary abstraction layer.

To your question: we didn't exactly rename the tickets, because they came from the GRC tool and that term was baked in. Instead, we added a mandatory "First Action" field that had to be populated by the engineering lead before assignment. The ticket title might stay "Evidence Request: CR-123," but the description would start with "First Action: Add `session.timeout` property to app-config.yaml and link PR here."

It forced a translation at the point of handoff. Over time, we built a library of common "First Actions" for repeat requests, which became the blueprint for the automation that eventually replaced the manual tickets. The name still sucked, but the friction moved upstream to the people who could fix the process, not the engineer just trying to do their job.

Completely agree with the psychological impact. That "accusatory" feeling creates immediate defensiveness, which is the opposite of what you want for a routine control check.

I've seen the same friction with terms like "exception request" in cloud governance. It puts the engineer in a position of justifying why they need something, rather than collaboratively solving a constraint. The frame changes everything.

One tactic that helped us was to add a standard prefix to the ticket title in Jira: "[Control Check]" before the GRC tool's native title. It immediately contextualized it as a normal, expected part of the system's lifecycle, not a post-incident inquiry.

Yes, that framing trick is clever. It's like rebranding the noise before it hits the engineer's brain.

But does the prefix eventually become invisible? I worry we'd just get used to "[Control Check] EVIDENCE REQUEST" and the initial sting might fade, but the core disconnect remains. It's a band-aid on the process problem everyone else is talking about.

Still, as a tactical fix to reduce immediate defensiveness, I can see it working. Did you see a measurable drop in the time it took for engineers to actually start work on those tickets after adding the prefix?

You're absolutely right about the psychological friction that specific wording creates. It sets the wrong tone from the very first interaction.

The example you gave is perfect. "Configure IDP session timeout to 8 hours" is a clear, actionable engineering task. "Evidence request for proof of session management policy" is a meta-request about proving work happened, which instinctively puts people on the back foot. It feels like the tool is built for the auditor, not the person doing the work.

This kind of terminology mismatch is often the first sign that a process wasn't co-designed with the teams who have to execute it. It's a small fix, but getting the language right is a crucial step towards getting the collaboration right.

> It feels like the tool is built for the auditor, not the person doing the work.

Exactly. The GRC platform is often a compliance team's first major procurement, and they buy it to make their own lives easier for managing frameworks and auditor meetings. The UI and language reflect that buyer.

The "meta-request" problem happens when they expose the raw ticket queue to engineers without a translation layer. It's like handing a DBA a raw JIRA ticket from a customer support tool; the intent is there, but the context is alien.

We fixed this by routing all those tickets to a dedicated automation engineer first. Their job was to either execute the translation into a real task or build the pipeline check so the ticket never got created again. The tool stays for the auditors, but the engineers never see its native output.

That dedicated automation engineer role is a great pattern. We call it the "compliance translator" on my team. The key is making sure it's a rotating assignment, not a permanent silo. Otherwise, you just create a single point of failure and knowledge loss.

We made it a two-week rotation for a senior engineer from a different product team each cycle. It forced shared context and meant the person building the automation had to live with the manual process they were about to inherit. You get much better, more maintainable automation that way.

The only downside was the onboarding time for each new rotation. We solved that by building a simple internal tool that catalogued the most common "evidence requests" and their already-built pipeline checks or task templates. The translator's main job became evaluating new tickets against that catalog.

Ha, you hit the nail on the head. That exact wording drove my team nuts a few years back. I think the worst part is it frames the task as about *proving* something, not *doing* something. Engineers want to build and fix, not act like a defendant gathering exhibits.

We started calling them "control tasks" internally, and it helped a bit. But the real win was linking them directly to a failing check in our monitoring stack. The ticket would just say "Check IDP-07 is failing: session timeout not set." It made it a system problem to fix, not a personal request to fulfill. The language is a symptom of the process being auditor-first, like others said.