NCSRC NIRMATA
Home Guides Framework Start Assessment →
Home › Guides › Supply-Chain Security › SCS-05
SCS-05 Supply-Chain Security 8% of OML score

Is access given to vendors limited only to what they need to perform their work?

When you give vendors (suppliers, service providers, consultants) access to your systems or data, are you making sure they can only see and do exactly what they need for their job? Or are they getting keys to everything like they're an employee?

⚡
Why This Matters to Your Business

If a vendor has access to more than they need and their login gets hacked, or they make a mistake, the damage spreads across your entire business. For example, if your accountant's laptop gets infected and they have access to your customer database instead of just financial records, you lose all customer information and face DPDP fines. If a delivery logistics vendor can see your product pricing system because they were given blanket access, a competitor could pay them to steal your pricing strategy. Limited access means when something goes wrong with a vendor, it stays contained to that one area instead of destroying your whole operation.

📊
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 give vendors whatever access they ask for or just hand them a shared login that works everywhere. You have no list of who has access to what, and vendors keep passwords written down or share them with their teammates.

Level 1
Initial

You know roughly which vendors need access to which systems, but you haven't written it down properly. When vendors call asking for access, you sometimes grant more than they actually need just to avoid follow-up calls.

Level 2
Developing

You have a simple list of vendors and what systems they use. You've set up separate user accounts for each vendor, but you rarely review whether they still need that access or if it's too broad.

Level 3
Defined

Each vendor has a documented access request form showing exactly what system and what functions they need. You review access every 6 months and remove it when the project ends, though you sometimes forget for low-priority vendors.

Level 4
Managed

Every vendor access request is formal: what they need, why, for how long, and at what permission level. You have role-based access so vendors only see the exact data or functions their job requires. You review quarterly and have a process to revoke access immediately when a vendor relationship ends.

Level 5
Optimised

Vendor access is governed by a formal policy. Each vendor gets the minimum access for their role, monitored continuously with automated alerts for unusual activity. You audit vendor access monthly, vendors sign agreements committing to access restrictions, and you test that deactivated accounts actually stop working.

🚀
How to Move Up — Practical Steps
StepWhat to DoWhoEffort
0 → 1 List all vendors who have access to any system today (accountants, IT support, delivery partners, consultants, etc.) and write down roughly what they access. Create a simple spreadsheet with vendor name, system access, and when access was given. Business owner or office manager 1-2 days
1 → 2 For each vendor, specify exactly which functions or data they actually need (e.g., 'accountant needs read-only access to invoices, not customer data' or 'IT vendor needs server admin access, not email'). Create individual login accounts for each vendor instead of sharing passwords. Document this in a simple form. IT person or business manager with IT knowledge 1 week
2 → 3 Create a formal 'Vendor Access Request Form' that must be filled out before any vendor gets access. Include: vendor name, what system/data, business reason, expiry date, and approval signature. Start using this form for all new vendor requests. Review existing vendor access and update the form for at least 50% of them. IT person or business manager 2-3 weeks
3 → 4 Set up role-based access control (RBAC) so vendors can only do what their job requires (e.g., 'View Invoice' vs. 'Edit Invoice'). Create a documented access policy. Implement a quarterly access review process with sign-off from department heads. Document that access was revoked for at least one vendor during the year. IT person with manager oversight 4-6 weeks
4 → 5 Add vendor access to your security monitoring: log who accessed what and when. Set up alerts for unusual vendor activity (access outside business hours, access to unexpected data, repeated failed logins). Include vendor access restrictions in vendor contracts. Run one audit test: verify that a deactivated vendor account is truly locked out across all systems. IT person, possibly with external security consultant 2-3 months
📁
Evidence You Should Have

Documents and records that prove your maturity level.

  • Vendor access register or spreadsheet listing all vendors, systems they access, permission level (read/write/admin), and when access was granted
  • Signed vendor access request forms showing business justification, approval, and expiry dates for at least 80% of active vendors
  • Role-based access policy document defining what each type of vendor (e.g., 'Accountant', 'IT Support', 'Delivery Partner') can and cannot access
  • Quarterly access review records showing which accounts were checked, who approved them, and which were disabled or modified
  • Vendor contracts or agreements that mention access restrictions and confidentiality obligations
🔍
What an Auditor Will Ask

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

  • "Walk me through how you grant a vendor access to your systems. What is the process and who approves it?"
  • "Can you show me your current list of all vendors who have system access? How often is it reviewed and updated?"
  • "Give me an example of a vendor who no longer works with you. When was their access removed and can you verify it's actually turned off?"
  • "If your accountant's login was compromised, what is the maximum damage they could do? What data or systems could they touch?"
  • "Do your vendor agreements include language about access restrictions and confidentiality? Can you show me an example?"
🛠
Tools That Work in India
PurposeFree OptionPaid Option
Create and track vendor access request forms and approval workflow Google Forms + Google Sheets, or Zoho Forms (free tier allows up to 3 forms) Zoho Creator (₹4,000-8,000/year for small business) or Microsoft Forms with Power Automate
Monitor and log who accessed what, when, and from where (especially important for sensitive data) Windows Event Viewer (built-in, requires manual setup) or Splunk Free (limited to 500MB/day) Splunk Enterprise (₹3,00,000+/year) or Zoho Analytics with audit trail (₹15,000-30,000/year)
Set up role-based access control and manage user permissions across systems Active Directory (built into Windows Server, if you have one) with documented access policies Microsoft Entra ID / Azure AD (₹5,000-20,000/year depending on licensing) or Okta (starts at ₹50,000+/year)
🛡
How This Makes You More Resilient
When vendor access is tightly controlled, a compromised vendor account or vendor mistake affects only one narrow area of your business instead of cascading across everything. A malicious or careless vendor cannot steal customer data, modify pricing, access source code, or sabotage operations because they simply don't have that capability. This dramatically reduces recovery time and regulatory fines if something does go wrong with a vendor.
⚠️
Common Pitfalls in India
  • Giving vendors admin or 'superuser' access because it's easier than setting up limited permissions—then forgetting to remove it after their project ends. Six months later, an old vendor still has full access.
  • Using shared login credentials for vendors (e.g., 'vendor@company') instead of individual accounts, so you can't tell which vendor actually did what and can't revoke one person's access without locking out everyone.
  • Setting vendor access with no expiry date. Once someone has it, you assume they still need it forever. When they move to a different company, their access silently remains active.
  • Not documenting vendor access at all, so when an auditor or incident happens, you realize you can't even list who had access or when they got it.
  • Giving vendors broader access to 'future-proof' for potential future needs that never happen, instead of regranting access on request when their needs actually change.
⚖️
Compliance References
StandardRelevant Section
DPDP Act 2023 Section 8 (Principles of Processing) and Schedule 2 (Consent and Notice for Sensitive Personal Data): requires limiting access to personal data to those who need it for defined purposes
CERT-In 2022 (Information Security Guidelines for CI/CII) Guideline 6.2.1 (Access Control): access privileges should be limited to the minimum required
ISO 27001:2022 Annex A, Control 6.2 (Segregation of Duties and Control of Access) and Clause 8.3 (Access Control)
NIST CSF 2.0 Protect Function (PR) - Identity Management, Authentication and Access Control (PR.AA and PR.AC)

Ready to assess your organisation?

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

Start Free Self-Assessment →

TRUST-IN Bharat · NIRMATA Framework · Licensed CC BY-SA 4.0 · Custodian: Elytra Security

← Back to all guides  ·  trustinbharat.org