What belongs under each ticketing label

Four labels, four populations: access covers anyone gaining, changing or losing access; system change covers changes to systems and configuration; vulnerability covers findings you have to remediate; incident covers things that went wrong, including customer complaints if privacy criteria apply to you. Deciding what goes in each is a judgment your auditor expects you to own, and it's the decision this article exists to help you make.

Scope each label narrowly and deliberately. The label defines what you're claiming to track and hold to a deadline, so a label that catches everything makes a promise you didn't intend to make.

Access

In: joiners, movers and leavers, plus any standalone access request — production access, an admin role, a new tool. Emergency or break-glass access — temporary elevated rights taken during an outage — belongs here too, and it's the case an auditor asks about by name.

Watch the halves teams forget. Everyone labels onboarding. Movers are next-most-missed: a promotion or team change adds permissions, and the old ones quietly stay. Leavers are the ones that matter most, and the first thing an auditor samples.

Raise terminations at your highest priority. Revoking a leaver's access has the shortest fuse of any work these tests cover — most frameworks expect it inside a business day, while new access typically gets a week. Giving terminations their own priority is what lets you hold them to their own deadline. A rule on your offboarding form can set it for you.

How this relates to access reviews: a ticket proves the event — this change was requested, approved and done on time. A review proves the state — today's list of who has access to what is correct. Auditors expect both, and neither substitutes for the other.

System change

In: infrastructure and environment changes, configuration that affects security or access, releases your policy says must be authorized, vendor or data-flow changes you initiate, and emergency out-of-band changes.

Out: routine pull requests and merges. If your version control system is connected, your Version control code review and Version control branch protection tests already cover code changes on the way in. Labelling every merge as a system change is the most common mistake here — it holds ordinary development to a change-management deadline for no compliance gain.

Also out: work that's really an incident, and anything in a non-production environment that can't reach production or customer data.

Emergency changes are the ones auditors ask about. Frameworks expect you to name, in advance, who can ship urgent fixes outside the standard process — and to record every time it happens. An unrecorded emergency change reads as an unauthorized one. Capture why it couldn't wait, who authorized the exception, what changed, and what review followed.

Vulnerability

In: findings you're responsible for remediating — from scanners, pentests, bug bounties, customer reports, and your own engineers. Teams often label only scanner output and leave the rest untracked.

Decide one ticket per finding, or one per scan. One per finding is cleanest to audit and it's a lot of tickets. One per batch is fewer, but each has to list what it covers and show each finding resolved. Either is defensible; mixing them isn't. Whichever you pick, high-priority findings need to be traceable individually — that's what the control asks for.

When you accept a risk instead of fixing it — a component you're retiring, a false positive, no patch available — record the acceptance in your risk register with who approved it, why, and when it's revisited. Then mark that one ticket Not Applicable with the same reason, so it isn't held to a deadline you've deliberately decided not to meet.

Where this ends: these tickets prove findings were tracked and closed on time. Your scan cadence — usually at least quarterly, with management review — is separate evidence.

Incident

In, and wider than most teams expect:

• Security incidents and suspected breaches, including the ones that turn out to be nothing. Suspected-and-dismissed tickets are evidence that people report things, which is exactly what an auditor is checking.
• Anything touching personal data. Unauthorized use or disclosure of personal information has to be tracked in an incident system.
• Customer inquiries, complaints and disputes, if SOC 2 privacy criteria apply to you — and data-subject grievances, complaints from the people whose personal data you hold, under India's Digital Personal Data Protection Act (DPDP). Most teams run these through a support inbox and have never considered them in scope.

If DPDP applies, your deadline is the number you published. DPDP asks you to publish the period you'll respond to grievances in and then meet it. Decide which priority a grievance lands on, set that deadline to the period on your website or privacy notice, and make sure no deadline on this label is longer than it.

An empty incident test isn't good news. Very few organizations genuinely had zero suspicious logins, zero phishing reports and zero complaints — usually none of it was written down. "We had no incidents" invites the next question. The strong answer is that you logged the near-misses too.

The boundaries people get stuck on

Common mistakes

• Widening a label to look thorough. It enrols work under a deadline it was never meant to carry, and one breach fails the whole test.
• Labelling only the easy half — onboarding but not offboarding, scanner findings but not pentest findings.
• Using one label for two kinds of work. Each label has its own deadlines; mixing populations means one set of numbers has to serve both.