A security incident rarely stays with security teams. The moment it involves a person, a dollar amount, a piece of equipment, or a regulator, it becomes someone else’s problem too. Who that someone else is, and how fast they need to know, changes depending on what your organization does and where it operates.

That’s the premise behind our new planning tool, The Cross-Functional Incident Workbook, which walks security leaders through six departments (HR, IT, Legal, Risk, Facilities, and Health & Safety) and maps out who owns what when an incident crosses department lines. The worksheets are built to flex to your organization, but the shape of the problem looks different depending on your industry. Here’s what that looks like across a few of them.

Finance: when an incident is also a compliance event

In financial services, a physical security incident can trigger a paper trail long before anyone finishes writing the initial report. A badge-access anomaly at a branch, a lost device belonging to someone with account access, or a break room theft investigation that touches an employee’s record all carry documentation requirements that security teams don’t own but still trigger.

Card data and payment environments raise the stakes further. If a physical incident touches an area where cardholder data is processed or stored, PCI DSS applicability should be flagged for accuracy before your team assumes the incident stays purely physical. The same goes for any incident involving access credentials tied to financial systems: IT and compliance need to know within the hour, not the weekly summary.

Manufacturing: when the incident stops production

On a plant floor, incident response competes with a production schedule, and every hour an incident goes unresolved can carry a cost that shows up in output rather than a police report. A contractor whose access should have ended with their work order, a safety incident on the floor, a theft of materials or finished goods: each of these has a different owner depending on whether it touches headcount, throughput, or the supply chain.

Manufacturers that move goods across borders also carry trade compliance obligations. Where an incident touches supply chain security or import and export controls, C-TPAT applicability should be flagged for accuracy rather than assumed. This is one of the clearer cases where legal and compliance need a seat at the table from the start of the response, not after the fact.

Retail: when the incident is also a brand exposure

Retail incident response has to account for two audiences that most other verticals don’t juggle at the same volume: the public and the media. A shrinkage investigation, a workplace violence incident on the sales floor, or a customer injury each carries its own internal handoff, but retail adds a layer where communications and PR need to know fast enough to get ahead of a story rather than react to one.

Multi-location retailers also deal with a version of the co-employment question that shows up differently across sites: contracted guards at one location, employees at another, seasonal staff everywhere. The RACI exercise in the workbook is built for exactly this kind of variation, where the same incident type can have a different owner depending on which site it happened at.

Property management: when one incident touches multiple stakeholders at once

A single incident at a managed property, a fire alarm, an unauthorized entry, an injury in a common area, can simultaneously involve the property owner, the tenant, a vendor, and the management company’s own liability. Facilities and risk teams in this space need incident data that’s specific enough to separate a minor maintenance issue from something that could become a claim.

Vendor and contractor access is a recurring theme in property management incident response. A maintenance worker’s badge, a security officer’s post assignment, a cleaning crew’s building access: each has a different revocation path, and each needs an owner named before the incident happens, not during it.

Public sector: when the incident becomes a public record

Government and public sector organizations carry a version of every challenge above, plus a records and transparency requirement that most private organizations don’t face in the same way. An incident report can become subject to a public records request, which changes what gets documented and how. Legal and compliance involvement isn’t optional here, and the handoff often needs to happen earlier than in other industries because the reporting clock and the public disclosure clock can run in parallel.

Multi-agency coordination adds another layer. A security incident on public property might need to route to a facilities department, a risk management office, and an external agency at the same time, and the workbook’s emphasis on naming a specific role (not just a department) is especially useful here, since public sector organizations often have more layers between “security saw it” and “the right person knows.”

The pattern that shows up everywhere

Across every vertical, the same gap keeps surfacing: contractor and vendor incidents follow a different path than the same incident involving an employee, and most organizations haven’t written that path down. Badge deactivation, background check status, and contract terms all change who owns the response, even when the incident itself looks identical on paper. That’s true whether you’re running a bank branch, a distribution center, a retail store, a managed building, or a public facility.

The other constant is this: the gap is easier to find on paper than in the middle of an actual incident. That’s the whole reason the workbook exists.

Download the Cross-Functional Incident Workbook and work through it with your own department leads. If your organization already uses TrackTik, the RACI grids you fill in can become the routing rules your platform runs on, so the plan doesn’t stay a document, it becomes the way incidents actually move.