How UprootSecurity decides whether a ticketing test passes

Two settings decide every ticketing test: the label picks which tickets get graded, and the deadline you set for each priority decides how long each of those tickets had. A test passes when every ticket it graded came in on time.

Set both on your ticketing integration, once per kind of work you track — access, system changes, vulnerabilities, incidents. Read this once and every ticketing test makes sense; what belongs under each label covers which tickets go where.

Which tickets get graded

The label picks the population. Only tickets carrying the label you chose are read. Choosing a narrow, deliberate label is the most important decision you make here, because it defines exactly what you're claiming to track. Azure DevOps and Zoho Sprints call a label a tag, and it works the same way.

Pick a label that already exists in your tracker. UprootSecurity offers the labels your tracker reports, so create the label there first and apply it to the work you want counted. On Azure DevOps and Zoho Sprints, choose your organization or team and project first — tags are read from the project you select, so point it at the project your compliance work lives in.

Common label names are recognized from the start. Tickets labelled "user-access", "system-change", "vulnerability" or "incident" are picked up straight away, so a team already using those names has a head start. Set your deadlines to finish the setup.

Monitoring starts when you connect. Tickets raised before then are out of scope, permanently — their clock ran under whatever process you had before, and grading them would judge old work by a new rule.

How each ticket is judged

The clock starts when the ticket was created — not when it was triaged, assigned, or picked up in a sprint. Time spent sitting in a backlog counts, which is usually where the time actually goes.

An open ticket is measured against today. An open ticket stays compliant right up until it passes its deadline. An open ticket is not a failing ticket.

A closed ticket is measured to its close date. A ticket that ran past its deadline stays on the record that way. That permanence is the point: an auditor can trust the timeline precisely because it isn't reshaped after the fact.

Deadlines run on the calendar. A one-day deadline is 24 hours, including nights and weekends, so a Friday-afternoon request is still counting on Sunday. Set numbers your team can meet on a weekend, or make sure someone is on point over one.

Give every labelled ticket a priority, and set a deadline for every priority you use. The deadline is looked up by the ticket's priority, so that pairing is what turns "we track this work" into "we track this work to a timeline." It's also the pairing an auditor asks about.

Choosing deadlines you can defend

Set each deadline to the timeline your own policy already commits to — your vulnerability and patch management policy, your incident response plan, your access policy, the response time published in your privacy notice. Not a number you're confident of hitting.

This is the judgment the whole feature rests on, and it's yours to own. A green test that contradicts your own policy is worse than a missed deadline, because the contradiction is easier for an auditor to find and harder for you to explain. If the number in your policy is wrong, change the policy deliberately and re-approve it.

What the verdict means

One breaching ticket fails the whole test. There's no partial credit — the test is the claim that this work is tracked to resolution, and a single overdue ticket makes the claim untrue.

Marking a single ticket Not Applicable is the supported lever. It carries your reason, sticks across future runs, and can be lifted again by the person who marked it. Use it for a ticket that carries the label by mistake, or for work you've formally decided not to do and recorded elsewhere. A handful with good reasons is normal. A pattern of them is what an auditor will pull on.

A test with no tickets is Pending, not failing. Nothing is broken — nothing has been observed yet. The honest read is that the label isn't in use, which is a real gap, just a different one.

Tests re-run every day, and you can run one on demand after you fix something.

Common mistakes

• Labelling more work than you meant to. The label defines what gets held to your deadline, so widening it enrols work that was never meant to be judged on that timeline.
• Setting deadlines you can hit rather than the ones you published. If these numbers don't match your own policy, the auditor reads the gap, not the green tick.
• Treating the starting numbers as a recommendation. Whatever you save becomes the commitment you're measured against.
• Closing a ticket you haven't finished. It's the one move that makes the evidence worse rather than better.