If a vendor suddenly gets access to more of your business data but nobody checks whether that's safe, you could end up with a breach—like when a logistics partner who only needed shipping addresses starts accessing customer payment information and gets hacked, exposing your customer base. An Indian manufacturing company once hired a new accountant through a vendor who then had access to GST records and bank details; when the vendor's office was ransomwared, the company's financial data was encrypted and held for ransom, costing ₹40 lakhs and regulatory penalties. Without reviewing vendor scope changes, you also fail customer audits: if a customer asks "who has access to our data?" and you can't show you reviewed it, you lose the contract. Regulators and insurers increasingly ask for proof of vendor risk review before paying claims.
Find where your organisation is today. Be honest — the self-assessment is only useful if it reflects reality.
Absent
You have no record of vendor agreements or what each vendor is allowed to do. When a vendor asks to do something new, you say yes or no based on gut feeling, and nothing is written down.
Initial
You have vendor contracts filed away somewhere, but when a vendor requests expanded access (like a CA asking for production system login), there's no formal process—your IT person and boss email about it loosely and it happens without documented security sign-off.
Developing
You have a basic vendor list with notes on what each one does, and you ask your IT person to think about security before approving major changes, but the decision and reasoning aren't formally recorded anywhere.
Defined
You have a vendor register with scope descriptions and a documented checklist (e.g., 'Does this vendor now access customer data? Does this need encryption review?') that you go through for every request, and you keep a record of approvals.
Managed
You have a formal vendor change request form, a documented risk assessment procedure (scoring access level, data sensitivity, and vendor security rating), documented approvals by business owner + IT, and an annual vendor scope review meeting.
Optimised
You have an integrated vendor risk management system that automatically flags scope changes, triggers a formal assessment using your vendor risk scoring model, requires cross-functional sign-off (business, IT, compliance), maintains a complete audit trail, and automatically triggers re-assessment of vendor security controls when scope changes.
| Step | What to Do | Who | Effort |
|---|---|---|---|
| 0 → 1 | Create a one-page vendor register listing each vendor name, what they do, and what data/systems they can access. Whenever a vendor asks for new access, send an email summary of the request to your IT person and document the decision in a shared folder. | Business Owner or Office Manager | 1 day |
| 1 → 2 | Design a simple one-page 'Vendor Scope Change Checklist' with yes/no questions: 'Does this change give access to customer data?', 'Does this change involve production systems?', 'Will this vendor now handle payment information?'. Use this checklist for every scope change and keep it with the vendor file. | IT Manager or Compliance Officer | 2-3 days |
| 2 → 3 | Create a formal 'Vendor Scope Change Request Form' (Google Form or printable) that the vendor or your team fills out. Define approval workflow: IT assesses security risk, business owner approves, signed approval is filed. Update your vendor register every quarter. | Compliance Officer with IT Manager input | 1-2 weeks |
| 3 → 4 | Build a vendor risk scoring matrix (data sensitivity: low/medium/high; vendor security rating: from past audits/assessments; access level: read-only/write/admin). Score each scope change request using this matrix, document the score and risk rating, and require sign-off from both business and IT. Maintain a change log. | Compliance Officer with IT and Business Owner | 3-4 weeks |
| 4 → 5 | Implement or configure a vendor management tool (paid or free) that triggers alerts when vendor scope changes are requested, auto-generates the risk assessment from your matrix, routes approvals electronically, and maintains a queryable audit log. Integrate with your annual vendor re-assessment cycle. | IT Manager or Compliance Officer | 1-2 months |
Documents and records that prove your maturity level.
- Vendor register or master list with each vendor, their original scope, and date scope was last reviewed
- Completed vendor scope change request forms signed by both IT and business owner for each change made in the last 12 months
- Vendor risk assessment documents or scoring sheets showing how you evaluated the security impact of each scope change
- Email chain or formal record documenting approval/rejection decisions and the reasoning (e.g., 'Approved: vendor already certified ISO 27001, data is non-sensitive')
- A change log or log entry showing the date, what changed, who approved it, and any conditions (e.g., 'Access limited to read-only', 'Requires VPN and 2FA')
Prepare for these questions from customers or third-party reviewers.
- "Walk me through a vendor scope change from the last 6 months—show me the request, your risk assessment, and the approval. How did you decide it was safe?"
- "List all vendors who have gained new access to systems or data in the last 12 months. For each one, show me the documented review."
- "What happens when a vendor calls and asks for new access? Walk me through your process step by step—do you have a form, a checklist, who approves it, and how long does it take?"
- "How do you know if a vendor's new scope creates a higher security risk than before? What criteria do you use to make that judgment?"
- "Show me your vendor register. How often is it updated? When was the last time you re-reviewed the scope of your critical vendors?"
| Purpose | Free Option | Paid Option |
|---|---|---|
| Simple vendor master list and change tracking | Google Sheets or Excel with shared access, plus a shared folder for approvals (zero cost, already available) | Airtable (₹5,000–10,000/year for team plan) or Microsoft 365 SharePoint (included if you have Microsoft licenses) |
| Vendor scope change request form and workflow | Google Forms (free) connected to Google Sheets auto-populated responses, or Formspree (free tier for up to 50 submissions/month) | Jotform (₹3,000–8,000/year) or Typeform (₹5,000–15,000/year) for branded forms with advanced routing |
| Vendor risk assessment and scoring | Excel risk matrix template (downloadable from ISO 27001 templates, zero cost) | OneTrust Vendor Risk Management (₹15,00,000+/year, enterprise-grade); ZeroCrash Vendor Manager (₹50,000–2,00,000/year for SME tier) |
- Treating vendor scope changes as routine IT tasks that don't need business approval—a developer quietly gives a new vendor database access to troubleshoot an issue, and nobody from the business side knows until an audit three months later.
- Assuming 'trusted vendors' don't need re-review—you've worked with an accounting firm for 5 years, they ask to start handling GST compliance (new scope), and you say yes without checking if their security posture has degraded or if this increases your compliance risk.
- Confusing 'we have a contract' with 'we reviewed this for security'—your SLA document describes scope, but there's no separate security impact assessment; when asked by a customer's auditor, you can't produce evidence of risk review.
- Losing track of cumulative access—a vendor started with hosting, then added backup, then added monitoring; no one noticed they now have admin access to almost everything because changes were approved one by one without stepping back.
- No change log or audit trail—you approved a vendor scope change verbally or in a Whatsapp group; three months later during a security incident, you can't prove when the access was granted or who authorized it, creating compliance and forensic problems.
| Standard | Relevant Section |
|---|---|
| DPDP Act 2023 | Section 8 (Purpose Limitation), Section 6 (Data Protection Principles). Vendors must only process personal data within agreed scope; scope changes without assessment violate purpose limitation. |
| CERT-In Guidelines 2022 | Guideline 5 (Audit and Logging). Organizations must maintain audit logs of access changes and authorization. Scope changes to vendors must be logged and approved. |
| ISO 27001:2022 | Annex A 5.3 (Segregation of Duties), A 6.2 (People with access to assets), A 8.1 (Personnel screening), A 8.3 (Asset management). Vendor access scope changes are part of asset management and access control. |
| NIST CSF 2.0 | Govern (GV.RO-02: Third-party risk management), Protect (PR.AC-01: Access granted), Detect (DE.CM-02: Review access). Covers vendor scope review as part of third-party risk and continuous monitoring. |
Ready to assess your organisation?
Answer all 191 questions and get your NIRMATA maturity score across all 12 pillars.
Start Free Self-Assessment →