Make the compliant ticket the default with templates and automation

Stop teaching people to raise compliant tickets and make your tracker do it instead. Templates carry the fields, automation carries the label and the priority, and intake carries the routing — three changes inside your own tracker that cover most of what these tests grade.

Training doesn't survive a quarter. People leave, an incident lands at 2am, someone raises a ticket from their phone. Anything that depends on remembering a label will be forgotten, and a forgotten label means the work is invisible to your compliance tests.

Templates carry the fields

Create one ticket type or template per kind of work: access, system change, vulnerability, incident. What belongs under each label covers where the boundaries fall. Put the five things a compliance ticket needs — who asked, who approved, what specifically changed, what proves it's done, and when — into the template's description as headings with blanks under them. What a ticket has to contain explains each one.

Now the person raising a ticket fills in blanks instead of recalling a standard. Each supported tracker has its own version of this — Jira request types and description defaults, Linear templates, Azure DevOps work item templates, Zoho Sprints templates. Whichever you use, the template should ship with the label already on it.

Payoff: your tickets stop being one-liners, without anyone being trained.

Automation carries the label and the priority

The label and the priority decide whether a ticket counts at all, and they're the two fields people skip most often. Don't ask for them — derive them.

• Stamp the label automatically. Put it on a ticket type, on a project or board, on tickets raised through a specific form, or on anything a scanner or alerting tool files. If a ticket lands in your vulnerability board, it gets the vulnerability label.
• Derive priority from severity. A critical scanner finding becomes a Critical ticket; a Sev-1 page becomes a Critical incident. Map it once in an automation rule rather than asking a tired engineer to choose.
• Set priority by ticket source where the deadline is fixed. Anything raised through your offboarding form should land at your tightest priority, because revoking a leaver's access has the shortest deadline of any work these tests grade.
• Backstop the blanks. A rule that sets a default priority when a labelled ticket has none takes ten minutes to build, and it means every ticket you're tracking has a deadline attached to it.

Payoff: your population is complete and every ticket in it has a bar to be measured against.

Intake carries the routing

Make the ticket exist before anyone decides to raise one.

• Access: a request form for onboarding, role changes and offboarding, wired into your HR or IT process — so a termination creates a ticket the day it's decided, not the day someone remembers.
• Vulnerabilities: your scanner files tickets directly, labelled and prioritized from the finding.
• Incidents: your alerting or on-call tool opens the ticket when it pages someone.

Payoff: the tickets that never got raised — the ones that quietly make your evidence incomplete — start existing.

What you must never automate

Automate creation, labelling, prioritization and routing. Keep approval, the severity call, and the decision to close in human hands, always:

• Approval. An auto-approval is not an approval. The entire point is that a person with authority agreed.
• The severity judgment. Derive a starting priority from a tool, but a human owns the call to raise or lower it, and the ticket should show why.
• The decision to close. Never auto-close on age, inactivity, or a passing rescan alone. An auditor reads an auto-closed ticket as an unresolved one, and a bot that closes tickets to beat a deadline is worse than a missed deadline. One exception - automations that close a ticket on resolution is acceptable - A workflow that closes a ticket when a System Change PR is merged to main.

A checklist you can work through in an afternoon

1. Create the four labels in your tracker, exactly as you'll configure them in UprootSecurity.
2. Build one template per kind of work, with the five fields and the label pre-set.
3. Add a rule that stamps the label on anything filed by a scanner, an alerting tool, or a request form.
4. Add a rule that gives any labelled ticket a priority if nobody set one.
5. Point your access requests at a form instead of a chat message.
6. Check your SLAs in UprootSecurity against the numbers your own policies already commit to, and fix whichever one is wrong.