Are incidents involving vendors reported and handled in a structured way?

When something goes wrong with a vendor—like they lose your data, get hacked, or fail to deliver critical service—do you have a clear, documented way to report it, investigate it, and fix it? This question asks whether your business handles vendor incidents in an organized, trackable manner instead of just making phone calls and hoping it works out.

⚡

Why This Matters to Your Business

Without a structured process, vendor incidents spiral: a vendor's data breach affecting your customer information takes weeks to discover, you don't know who to contact or what information to share, and by the time you act, customers are already complaining and regulators are knocking on your door. A real Indian scenario: a logistics vendor's cloud account is compromised, your shipment data leaks to competitors, but because you have no incident reporting process, you only find out when a customer tells you they received competitor pricing. This costs you the customer, damages your reputation, and exposes you to regulatory action under the DPDP Act for not detecting and reporting a third-party breach promptly.

📊

What Each Maturity Level Looks Like

Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.

Level 0
Absent

You have no documented vendor incident process at all. When a vendor has a problem, people call each other randomly, someone might email about it, and there's no record of what happened, who reported it, or how it was resolved.

Level 1
Initial

You have an informal list of vendor contacts and people know to call the procurement person if something goes wrong. There's no written process, no template for reporting, and incidents are tracked by email thread or WhatsApp messages, making it hard to trace what happened.

Level 2
Developing

You have a basic written process (one-page document) that says 'report vendor incidents to the IT manager,' and you keep a simple log or spreadsheet of incidents with date, vendor name, and brief description. However, you don't have a formal template and there's no standard way to investigate or close incidents.

Level 3
Defined

You have a documented vendor incident reporting process with a clear template, defined escalation steps, and a central incident register. When an incident is reported, you follow the same steps every time: log it, investigate, document findings, notify the vendor, and record the resolution. You review incidents quarterly.

Level 4
Managed

Your vendor incident process is integrated with your overall security incident management; you have defined roles (who investigates, who approves actions, who notifies customers), clear timelines (acknowledge within 24 hours, investigate within 3 days), and a formal closure process. You conduct root cause analysis on serious incidents and track trends to identify risky vendors.

Level 5
Optimised

Vendor incident management is fully automated with a ticketing system; incidents are automatically categorized by severity, assigned to the right person, and escalated if not addressed within SLA timeframes. You have regular drills, you share incident insights with vendors in a formal feedback loop, and you use incident data to adjust vendor SLAs and security requirements annually.

🚀

How to Move Up — Practical Steps

Step	What to Do	Who	Effort
0 → 1	Create a simple one-page document listing all vendors, their primary contacts, and a phone tree for who to call if something goes wrong (e.g., 'If vendor is down, call Procurement Head; if data is involved, call IT'). Post it in the office and email it to the team.	Procurement Manager or IT Owner	1 day
1 → 2	Design a basic vendor incident form (1-page, in Word or Google Docs) with fields: date, vendor name, incident type (data, service down, security), description, who reported it, immediate actions taken. Create a shared folder or spreadsheet to log all incidents; commit to filling it out within 1 day of discovery.	IT Manager and Procurement Manager	3-5 days
2 → 3	Expand the incident form to include investigation steps (who will investigate, by when, what evidence to collect), vendor notification protocol, and closure criteria. Assign a single person as 'Incident Coordinator' with responsibility to track all vendor incidents. Hold a 30-minute training for all team leads on how to report an incident properly.	IT Manager	2-3 weeks
3 → 4	Implement a simple ticketing system (Jira, Zoho Desk, or open-source Osticket) for vendor incidents; define SLAs (e.g., acknowledge within 24 hours, investigate within 3 days). Create role-based access so vendors can report directly if needed. Conduct quarterly incident review meetings to discuss trends and update vendor contracts with SLA expectations.	IT Manager with support from Procurement and senior leadership	1-2 months
4 → 5	Automate incident routing based on type and vendor criticality; integrate incident tracking with vendor scorecards so repeated incidents trigger vendor review. Conduct tabletop exercises twice yearly to test incident response with vendors. Establish a vendor security council that reviews incidents, shares learnings, and updates vendor security requirements based on incident patterns.	IT Manager, CISO (if designated), Procurement, and Legal	Ongoing (4-6 hours per month)

📁

Evidence You Should Have

Documents and records that prove your maturity level.

Written vendor incident reporting process document (dated and version-controlled)
Vendor incident form or template with required fields (date, vendor, type, reporter, actions, closure)
Incident register or log showing at least 3-5 past vendor incidents with date reported, description, investigation notes, and resolution
Vendor contact list with primary and backup contacts, escalation points, and communication channels
Evidence of at least one incident being escalated, investigated, and closed (email trail, notes, or ticket record showing follow-up)

🔍

What an Auditor Will Ask

Prepare for these questions from customers or third-party reviewers.

"Walk me through your process for reporting a vendor incident. If a vendor's system went down and affected your operations, what would you do and who would you tell?"
"Show me your vendor incident log for the last 12 months. How many incidents have you recorded? What were they, and how were they resolved?"
"If a vendor suffered a data breach involving your customer data, how would you find out, and what would you do in the first 24 hours?"
"Do your vendor contracts specify how and when they must notify you of a security incident? Can you show me an example?"

🛠

Tools That Work in India

Purpose	Free Option	Paid Option
Simple incident tracking and logging	Google Forms + Google Sheets: Create a form for incident reporting, responses auto-populate into a spreadsheet for tracking and analysis	Zoho Desk (₹2,500-5,000/month) or Jira (₹3,000-8,000/month for small team): Full-featured ticketing with escalation, SLA tracking, and reporting
Document and process management	Google Docs or LibreOffice: Write and version-control your incident process document and forms	Confluence (₹5,000-10,000/month) or SharePoint: Centralized repository for policies, processes, and incident records with access controls
Vendor contact and communication management	Google Contacts + Gmail: Maintain vendor contact list and email history in one place	HubSpot CRM free tier or Zoho CRM (₹1,500-3,000/month): Track all vendor interactions, escalations, and communication in one record

🛡

How This Makes You More Resilient

With a structured vendor incident process, you catch problems faster (instead of hearing about them from angry customers), you respond consistently without confusion, and you have evidence to show regulators or customers that you handled the issue responsibly. This reduces the cost of incidents, protects your reputation, and makes it much harder for a single vendor failure to spiral into a major business disruption.

⚠️

Common Pitfalls in India

Assuming vendor incidents are 'their problem': Many Indian MSMEs assume that if a vendor is breached or their service fails, it's entirely the vendor's responsibility. In reality, if customer data is affected, regulators hold you accountable too. Your incident process must cover both your vendor's failures and your response.
Relying on verbal communication and WhatsApp: Incidents reported over chat or calls leave no audit trail. When a regulator or customer asks 'When did you first know about this?' you can't prove it. Always document incidents in writing, with timestamps.
No escalation criteria: Without clear rules on what counts as 'serious,' a data leak and a minor service delay get the same level of response. Define severity levels (Critical = customer data involved; High = service down for >4 hours; Medium/Low = performance issues or minor delays) and escalate accordingly.

⚖️

Compliance References

Standard	Relevant Section
DPDP Act 2023	Section 4 (rights and responsibilities), Section 7 (notice of personal data breach to Chief Information Commissioner), Section 8 (notification to affected individuals). Structured incident reporting ensures you detect and report breaches within the statutory timeframe.
CERT-In 2022	Directions 3, 5, and 6 (incident reporting, vulnerability management, log retention). Third-party breaches must be reported; a structured process ensures you meet reporting timelines.
ISO 27001:2022	Clause A.5.17 (supplier relationships), A.5.34 (incident management), A.8.32 (incident handling and improvement). Requires documented processes for managing supplier incidents and communicating with them.
NIST CSF 2.0	Detect (DE.CM-1 Adverse network behavior is detected and identified; DE.AE-3 Recovery procedures are tested). A structured process enables detection of vendor-related security events and coordinated response.

Ready to assess your organisation?

Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.

Start Free Self-Assessment →