The Short Answer
An incident response plan is a short document that says who does what when something goes wrong with client content, such as a lost drive, a mis-sent link, ransomware on the NAS or a suspected leak. The MPA Best Practices require a formal plan that covers both IT incidents and content incidents. A small vendor can write a useful one in a few pages. What matters is that people have read it before the bad day.
What the Best Practices Ask For
The incident response control (OR-4.0 in version 5.3.2) says to establish and regularly review a formal policy and process that includes:
- Detection and analysis
- Escalation
- Response
- Evidence and forensics
- Remediation
- Reporting and metrics
- A corrective action process with root cause analysis and lessons learned
- Timely notification of affected business partners and clients
- Use of the Alliance for Creativity and Entertainment's reporting page for piracy incidents
The Additional Recommendations go further: a response team with a designated lead, addressing incidents within 48 hours, telling impacted clients as soon as possible with high-level details, regular updates on an agreed cadence, applying the plan to freelancers and visitors as well as staff, keeping contact details for partners and clients, notifying law enforcement where appropriate, anonymous reporting, and hiring a third-party cybersecurity partner when needed. The disaster recovery control also expects the plan to be part of your recovery plan and, as a recommendation, tested through tabletop exercises.
NIST's incident response guide (SP 800-61 Revision 3, April 2025) treats incident response as part of overall cybersecurity risk management rather than a stand-alone activity. That fits a small shop: the plan, backups, access control and training are one system.
The Outline
1. Purpose and scope
Two sentences on what the plan covers: client content on your premises, in the cloud and with freelancers, and the systems that hold it.
2. Roles
- Incident lead. One named person with a named backup.
- IT contact. Your in-house person or IT partner.
- Client communications. The person who speaks to clients. Usually the same as the lead in a small shop.
- Decision maker. The owner, who can approve spending and shutting systems down.
3. What counts as an incident
Write examples so nobody debates it: a lost or stolen drive or laptop, a link sent to the wrong person, an unexpected login, ransomware, a phishing click, a suspected leak of a cut, a visitor found in a restricted room.
4. The contact sheet
Keep a printed copy, because email may be down. Include the lead and backup, IT partner, each client's security or production contact, your insurer if you have cyber coverage, legal counsel and the building manager. Check each client contract for notification terms and write the deadline next to the client name. This post is not legal advice, so ask counsel what applies to you.
5. The first hour
- Write down the time and what you saw. Facts only.
- Tell the incident lead. Do not wait for certainty.
- Contain. Disconnect affected machines from the network, revoke the link or credentials, disable the account.
- Preserve evidence. Do not wipe, reformat or reinstall. Keep logs, screenshots and the affected device.
- Stop sharing the content. Pause transfers for the title involved.
6. Client notification
Say what you know, what you do not, what you have done and when you will update. Do not guess about cause. Agree on an update schedule. The Best Practices recommendations point toward telling clients quickly with high-level details and then updating them as the investigation moves.
7. Investigation and recovery
Find how it happened, remove access, patch or reconfigure, then restore from a backup you have actually tested. Bring in a third-party specialist if you cannot be sure the environment is clean. For storage and backups, see backup strategy for video production.
8. Piracy and leak reporting
If a title has leaked publicly, use the reporting page the Best Practices name and tell the client at once. Do not contact the person you suspect.
9. After action review
Within a couple of weeks, run a short review: timeline, root cause, what worked, what to change. Update the plan, the training and the controls. The Best Practices call for root cause analysis and lessons learned as part of the corrective action process.
10. Practice
Once a year, run a one-hour tabletop. Pick a scenario ("the NAS is encrypted and there is a ransom note"), walk through the plan out loud and fix what does not work. Keep notes. Assessors like to see them, as do clients.
What To Keep As Evidence
The plan with its review date, the training log, the tabletop notes, the contact sheet and, after any real incident, the timeline and corrective actions. If you cover freelancers, include them in the training log.
Common Mistakes
- A plan that lives only in a shared drive that ransomware would encrypt
- No named backup for the lead
- Wiping the machine before anyone has copied the logs
- Telling the client late because the facts were not complete
- A contact sheet that still lists someone who left last year
For the broader picture of studio threats, see cybersecurity for post-production studios.
Want a person to help?
A real person on our team can draft the plan with you, build the contact sheet, set up the logging and backups it depends on, and run the first tabletop. We help you get ready. If something is already happening, tell your clients and your insurer first, then contact us if you want a second pair of eyes. The assessment itself is done by an independent TPN-accredited assessor, and we do not give legal advice or guarantee outcomes. See our network security services, or plug us in.
Write a content security incident response plan for a small vendor
Name the roles
Choose an incident lead and a backup, plus an IT contact, a client communications owner and a decision maker.
Define what counts as an incident
List examples such as lost drives, mis-sent links, ransomware, phishing clicks and suspected leaks.
Build a printed contact sheet
Include internal contacts, clients, IT partner, insurer and counsel, with each client notification deadline from the contract.
Write the first-hour steps
Record facts, alert the lead, contain, preserve evidence and pause transfers for the affected title.
Prepare the client message
State what you know, what you do not know, what you have done and when the next update will come.
Plan recovery
Restore from tested backups, find the root cause and bring in a specialist if the environment may not be clean.
Review and practice
Hold an after action review within a couple of weeks and run an annual tabletop exercise, keeping notes as evidence.
Questions people ask
Does TPN require an incident response plan?
Yes. The Best Practices include a Best Practice for a formal incident response policy and process that covers both IT incidents and content incidents, including notifying affected clients in a timely manner.
How soon do we have to tell a client about an incident?
The Best Practices say timely, and a recommendation says as soon as possible with high-level details. The binding deadline is whatever your client contract says, so read it in advance and ask counsel if it is unclear.
How long should the plan be?
A few pages are enough for a small vendor if roles, contacts and the first hour are clear. A plan nobody reads fails no matter how long it is.
Do we need to test the plan?
The Best Practices list testing through tabletop exercises as a recommendation for the disaster recovery plan. An annual one-hour tabletop is a cheap way to find gaps.
Written by the team at Clouds Agency, a Los Angeles creative and production consulting agency.