ISO 27001 A.8.30: Outsourced Development

Quick Reference (60 Seconds)

Control: A.8.30, Outsourced Development
Purpose: Ensure security requirements are defined, communicated, and enforced when software development is outsourced to third parties, protecting the organization from supply chain risks.
ISO 27002 attributes: Control type: Preventive, Detective · Properties: Confidentiality, Integrity, Availability · Concepts: Identify, Protect, Detect · Capabilities: System and network security, Application security, Supplier relationships security · Domains: Governance and ecosystem, Protection
Who it applies to: All organizations that use third-party developers, offshore teams, contractors, or managed development services.
Minimum viable actions:

• Include security requirements in all outsourcing contracts and RFPs
• Conduct security due diligence before selecting vendors
• Require vendors to comply with your secure development lifecycle
• Perform security acceptance testing on all vendor deliverables
• Maintain audit rights and right-to-assess clauses in contracts

Key deliverables: Outsourced Development Security Policy, Vendor Security Requirements, Contract Security Clauses, Vendor Assessment Report, Security Acceptance Checklist.

Audit questions you should be able to answer:

• How do you ensure outsourced developers follow your security requirements?
• What security clauses are in your outsourcing contracts?
• How do you assess vendor security before engagement?
• What security testing is performed on vendor-delivered code?

What the Control Asks For

Do you need this control?

A.8.30 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you outsource any development. If all development is in-house or you buy only off-the-shelf software, you can exclude it with that reason.

Annex A 8.30 asks organizations to direct, monitor, and review outsourced system development.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.30), paraphrased: communicate and agree requirements and expectations with the developer, then continually monitor and review whether the work meets them. Consider, across the whole external supply chain (including the vendor's own subcontractors):

• (a) licensing, code ownership and intellectual property rights for the outsourced work (5.32);
• (b) contract requirements for secure design, coding and testing (8.25 to 8.29);
• (c) giving external developers the threat model to work from;
• (d) acceptance testing of the quality and accuracy of deliverables (8.29);
• (e) evidence of minimum security and privacy capabilities, such as assurance reports;
• (f) evidence of testing for malicious content, intentional or not, on delivery;
• (g) evidence of testing for known vulnerabilities;
• (h) source-code escrow, for example if the supplier fails;
• (i) a contractual right to audit development processes and controls;
• (j) security requirements for the development environment (8.31);
• (k) applicable legislation, such as personal data protection.

The ISO/IEC 27036 series gives more on supplier relationships.

What the Standard Does NOT Require

• The standard does not mandate that all development be in-house
• It does not require specific vendor certifications (though they may be beneficial)
• It does not require continuous monitoring of every vendor action, but rather appropriate oversight based on risk
• It does not prevent offshore or nearshore development when security controls are applied

Why Outsourced Development Security Matters

The Supply Chain Risk

Outsourced development introduces a supply chain risk that is often underestimated. The vendor has:

• Access to your source code, architecture, and business logic
• Access to your data (test data, production data, customer data)
• Access to your systems (development environments, repositories, CI/CD pipelines)
• The ability to introduce backdoors, vulnerabilities, or malicious code
• Control over components that will run in your production environment

Real-world incidents:

• SolarWinds (2020): Attackers compromised the software build process of a third-party vendor, inserting backdoors into updates that were distributed to 18,000+ organizations, including Fortune 500 companies and government agencies.
• Codecov (2021): Attackers compromised the Bash Uploader script used by Codecov, a code coverage tool. The script was used by thousands of organizations, and the compromise exposed environment variables and credentials from CI/CD pipelines.
• Kaseya VSA (2021): Attackers exploited a zero-day vulnerability in Kaseya's VSA software, a remote management tool used by MSPs. The attack impacted up to 1,500 downstream businesses through the supply chain.
• Log4j (2021): While not an outsourcing issue per se, it demonstrated how a single third-party component can create systemic risk across millions of applications.

The Indian Context

• Massive outsourcing volume: Indian vendors serve Fortune 500 companies, governments, and startups globally
• Offshore access: Vendors have remote access to client systems, repositories, and data
• Data residency concerns: Client data may be processed in India, requiring DPDP Act 2023 compliance
• IP protection: Source code and algorithms are valuable intellectual property at risk of theft or misuse
• Subcontracting: Vendors may further subcontract work, creating invisible supply chain risks
• Regulatory compliance: Vendors must comply with client regulations (PCI DSS, GDPR, HIPAA, RBI)
• Talent turnover: High employee turnover in Indian IT services can lead to knowledge gaps and security inconsistencies

Scope and Applicability

In Scope

This control applies to:

• Full outsourcing: Complete application development by third-party vendors
• Partial outsourcing: Modules, components, or features developed by contractors
• Offshore development: Development performed by teams in other countries
• Nearshore development: Development performed by teams in neighboring countries
• Staff augmentation: Contract developers working within your organization
• Managed services: Third-party teams managing development operations
• Subcontracting: Vendors further subcontracting work to other parties
• Open source development: Customization of open source components by third parties
• Cloud development services: Using cloud-based development platforms managed by third parties

Out of Scope (with caveats)

• COTS software procurement (covered by A.5.24, A.8.9)
• Unmodified SaaS services (covered by A.5.24, A.8.8)
• Hardware procurement (covered by A.7.10, A.8.1)
• IT support services without development (covered by A.6.1, A.8.1)

Caveat: If a SaaS vendor customizes code for you, or if COTS requires significant customization, outsourced development controls apply.

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Directly Related Controls

Framework Mapping

Implementation Roadmap (Week-by-Week)

Figure · Tiers

Maturity levels for outsourced development

Phase 1: Foundation (Weeks 1–3)

Week 1: Policy and Contract Templates

• Draft the Outsourced Development Security Policy
• Create security requirements template for RFPs
• Develop contract security clauses (MSA, SOW, NDA, DPA)
• Define vendor security assessment criteria

Week 2: Vendor Assessment Framework

• Create vendor security assessment questionnaire
• Define vendor risk scoring methodology
• Establish vendor security tiers (critical, high, medium, low)
• Create vendor onboarding security checklist

Week 3: Baseline Assessment

• Inventory all current outsourced development vendors
• Assess current vendor security posture
• Identify gaps and high-risk vendors
• Document baseline metrics

Deliverables: Policy draft, Contract templates, Assessment framework, Vendor inventory, Baseline report

Phase 2: Pilot (Weeks 4–6)

Week 4-5: Pilot Vendor Assessment

• Select 2-3 critical vendors for pilot assessment
• Conduct security assessments using the questionnaire
• Review vendor contracts and add security clauses
• Test security acceptance process for one deliverable

Week 6: Refinement

• Refine assessment questionnaire based on pilot feedback
• Update contract templates with lessons learned
• Improve acceptance testing process
• Train vendor managers on security requirements

Deliverables: Pilot assessments, Updated templates, Improved process, Trained staff

Phase 3: Rollout (Weeks 7–12)

Week 7-9: Organization-Wide Deployment

• Assess all existing vendors using the framework
• Update all contracts with security clauses (where feasible)
• Implement security acceptance testing for all vendor deliverables
• Establish vendor monitoring and review schedule

Week 10-12: Process Integration

• Integrate vendor security into procurement process
• Integrate vendor security into project management
• Establish vendor security dashboard
• Implement ongoing vendor monitoring

Deliverables: All vendor assessments, Updated contracts, Acceptance testing deployed, Monitoring established

Phase 4: Optimization (Weeks 13–16)

Week 13-14: Metrics and Monitoring

• Define and collect KPIs (see Section 13)
• Conduct first internal audit of vendor security process
• Identify gaps and improvement opportunities

Week 15-16: Continuous Improvement

• Update assessment questionnaire with new threats
• Implement automated vendor monitoring where possible
• Enhance vendor security training
• Update contract templates with regulatory changes

Deliverables: KPI dashboard, Internal audit report, Updated templates, Automated monitoring

Maturity Model

Detailed Implementation Guidance

The Outsourced Development Security Lifecycle

Vendor Selection → Contract Negotiation → Onboarding → Development → 
Delivery → Acceptance → Deployment → Monitoring → Offboarding

Stage 1: Vendor Selection

Security Due Diligence Checklist:

Vendor Risk Scoring:

Stage 2: Contract Negotiation

Essential Security Contract Clauses:

1. Security Requirements Clause:

Vendor shall comply with all security requirements specified in 
Attachment A (Security Requirements). Vendor shall implement 
security controls at least equivalent to the client's ISO 27001 
security controls. Vendor shall not introduce vulnerabilities, 
backdoors, or malicious code into deliverables.

2. Data Protection Clause:

Vendor shall process all client data in accordance with the 
Data Processing Agreement (Attachment B). Vendor shall encrypt 
all client data in transit (TLS 1.3) and at rest (AES-256). 
Vendor shall not use client data for any purpose other than 
performing the services. Vendor shall delete all client data 
within 30 days of contract termination.

3. Right-to-Audit Clause:

Client reserves the right to audit vendor's security controls 
with 30 days' notice, not more than twice per year. Vendor 
shall provide access to relevant personnel, documentation, 
and systems. Vendor shall remediate any findings within 60 days.

4. Code Quality and Security Testing Clause:

All deliverables shall undergo SAST, DAST, and SCA before delivery. 
Vendor shall provide security test reports with each deliverable. 
Zero critical vulnerabilities and no more than [X] high 
vulnerabilities are acceptable. All medium vulnerabilities 
must be tracked for remediation.

5. Subcontracting Clause:

Vendor shall not subcontract any work without client's prior 
written consent. Any approved subcontractor must sign security 
agreements equivalent to this contract. Vendor remains 
liable for subcontractor security breaches.

6. Incident Notification Clause:

Vendor shall notify client of any suspected or actual security 
incident affecting client data, code or systems within [2-4] hours 
of becoming aware, so that client can meet CERT-In's 6-hour 
reporting rule and sector regulator timelines. Vendor 
shall cooperate fully in incident investigation and remediation.

7. IP Protection Clause:

Vendor hereby assigns to Client all right, title and interest,
including copyright, in all deliverables and work product created
under this Agreement, worldwide and for the full term of
protection (Copyright Act 1957, ss.18-19), and waives moral rights
to the extent permitted. Vendor grants Client a perpetual licence
to any pre-existing Vendor materials embedded in the deliverables.
Vendor shall list all open-source and third-party components and 
their licences in the deliverables. Vendor shall not use client IP 
for any other purpose. Vendor shall not disclose client code or 
architecture to third parties. Code escrow arrangement shall 
be maintained per Attachment C.

Indian law note. Under the Copyright Act 1957, s.17, the contractor (not the client) is the first owner of code its staff write, unless the code is made under a contract of service (employment). Ownership moves only by a written assignment (s.18–19) that identifies the work, the rights, the duration and the territory. If duration is not stated it defaults to 5 years (s.19(5)), and if territory is not stated it defaults to India (s.19(6)). Use present-tense words of assignment ("hereby assigns"), state worldwide and full term, and have counsel review the clause.

11. Threat Model and Requirements Clause:

Client shall provide Vendor with the threat model and security 
requirements for the work. Vendor shall design and test against 
them and report any threat it identifies that the model misses.

12. Delivery Evidence Clause:

With each release Vendor shall deliver: SAST and SCA results; an 
SBOM (CycloneDX or SPDX); a malware scan of the delivered 
artefacts; penetration test results for major releases; and a 
statement that the threat model's mitigations are implemented. 
Client may reject any delivery without this evidence.

13. Development Environment Clause:

Vendor shall develop client code only in client-controlled 
repositories and environments (or Vendor environments approved in 
writing), using managed devices with disk encryption and endpoint 
protection, MFA, and VPN or virtual desktop access. No client code 
or data on personal devices. Vendor shall return or delete client 
code and data, and Client shall revoke access, at engagement end.

14. Personal Data (DPDP) Clause:

Where Vendor processes personal data for Client, it does so only 
under the data processing terms in Attachment B, on Client's 
instructions, with reasonable security safeguards, and with 
support for data principal requests and breach intimation 
(DPDP Act 2023, s.8).

8. Personnel Security Clause:

Vendor shall conduct background checks on all personnel 
accessing client systems or data. Vendor shall ensure 
personnel sign confidentiality agreements. Vendor shall 
notify client of personnel changes affecting the engagement.

9. Compliance Clause:

Vendor shall comply with all applicable regulations including 
PCI DSS, GDPR, DPDP Act 2023, RBI guidelines, and SEBI 
regulations as applicable. Vendor shall provide compliance 
attestations annually.

10. Liability and Insurance Clause:

Vendor shall maintain cyber insurance with minimum coverage 
of [X] crore. Vendor shall be liable for damages resulting 
from vendor-introduced security breaches. Vendor shall indemnify 
client for regulatory fines resulting from vendor negligence.

Stage 3: Onboarding

Vendor Onboarding Security Checklist:

Stage 4: Development Monitoring

Ongoing Vendor Security Monitoring:

Vendor Activity Monitoring:

• All vendor access to client systems is logged
• Vendor code commits are reviewed for security
• Vendor access to production is restricted and monitored
• Vendor data downloads are tracked and alerted
• Vendor VPN/access sessions are time-limited and reviewed

Stage 5: Delivery and Acceptance

Security Acceptance Process:

1. Deliverable Submission: Vendor submits code with security test report (SAST, DAST, SCA results)
2. Automated Validation: Client runs SAST, SCA, and secrets detection on delivered code
3. Manual Review: Client security team reviews critical/high-risk code paths
4. Penetration Testing: Client or third party conducts penetration test on delivered application
5. Vulnerability Triage: Findings are triaged, severity assigned, and remediation timeline agreed
6. Remediation: Vendor fixes vulnerabilities within SLA
7. Re-testing: Client verifies fixes
8. Security Sign-off: Client security team approves deliverable for deployment
9. Deployment: Code is deployed through client's change management process

Delivery evidence pack (acceptance gate, 27002 8.30(c)–(g)):

Acceptance Criteria:

• Zero critical vulnerabilities in SAST/DAST/SCA
• All high vulnerabilities remediated or risk-accepted with security lead approval
• No hardcoded secrets detected
• All dependencies scanned and approved
• Security test report provided and reviewed
• Architecture diagram provided and reviewed
• Data handling verified (no production data used in testing)
• Compliance requirements verified

Stage 6: Deployment and Ongoing Monitoring

Post-Deployment Vendor Security:

• Vendor access to production is revoked or severely restricted
• Vendor support access requires ticket-based approval with time limits
• Vendor patches and updates are security tested before deployment
• Vendor component vulnerabilities are monitored via SCA
• Vendor security incidents are tracked and evaluated
• Vendor compliance attestations are reviewed annually

Stage 7: Offboarding

Vendor Offboarding Security Checklist:

Special Scenarios

Offshore Development (India to US/EU/UK)

Additional Considerations:

• Data residency: EU data must stay in EU; consider data localization requirements
• GDPR/DPDP Act: Cross-border transfer requirements (GDPR: SCCs or adequacy; DPDP: no transfers to government-restricted countries)
• Time zone coordination: Security incident response across time zones
• Cultural differences: Security awareness and practices may differ
• Regulatory compliance: Vendor must comply with both Indian and client-country regulations
• Export controls: Technology export restrictions (cryptography, defense-related)
• Tax and legal: Contract jurisdiction, dispute resolution, liability

Mitigation Strategies:

• Use dedicated offshore development centers with enhanced security
• Implement data minimization (only necessary data leaves the client country)
• Use synthetic/anonymized data for offshore development
• Implement strong encryption for all data transfers
• Establish 24/7 security operations with overlap hours
• Conduct regular on-site audits of offshore facilities

Subcontracting Management

Subcontracting Risks:

• Primary vendor may subcontract to unknown parties
• Security requirements may not flow down to subcontractors
• Client may not know who is actually writing the code
• Subcontractors may be in high-risk jurisdictions

Mitigation Strategies:

• Contractual prohibition on subcontracting without approval
• Mandatory subcontractor security assessment
• Subcontractor security clauses equivalent to primary contract
• Primary vendor liability for subcontractor breaches
• Right to audit subcontractors
• Subcontractor personnel screening requirements

Open Source Development with Vendor Customization

Risks:

• Vendor introduces vulnerable open source components
• Customizations may introduce new vulnerabilities
• Open source license compliance issues
• Community support vs. vendor support confusion

Mitigation:

• SCA for all open source components in deliverables
• License compliance review
• Vendor responsible for open source vulnerability patching
• Community vs. vendor support model documented
• Backporting policy for security patches

Cloud-Based Development (Vendor-Managed Platforms)

Risks:

• Vendor uses cloud platforms (GitHub, GitLab, AWS CodeCommit) with shared infrastructure
• Multi-tenant environments may have data leakage risks
• Vendor's cloud security posture affects client security
• API keys and credentials in cloud environments

Mitigation:

• Vendor cloud security assessment
• Dedicated cloud instances where possible
• Cloud access logging and monitoring
• Encryption of data at rest in cloud
• Vendor cloud security configuration review

Tools, Technologies, and Solutions

Vendor Risk Management Platforms

Code Security and Repository Tools

Contract and Document Management

Vendor Monitoring and Audit Tools

Indian Vendor Security Assessment Resources

Policy and Procedure Templates

Outsourced Development Security Policy (Template)

Vendor Security Assessment Questionnaire (Template)

Risk Assessment and Treatment

Risk Assessment for Outsourced Development

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "How do you assess vendor security before engagement?"
2. "What security clauses are in your outsourcing contracts?"
3. "Can you show me a vendor security assessment?"
4. "How do you ensure vendor code is secure before acceptance?"
5. "What happens if a vendor introduces a security vulnerability?"
6. "How do you handle vendor subcontracting?"
7. "Are vendor security incidents reported to you?"
8. "How do you protect your IP when outsourcing?"
9. "What is your vendor offboarding process?"
10. "How do you monitor vendor compliance with security requirements?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│                  OUTSOURCED DEVELOPMENT SECURITY DASHBOARD          │
│                    [Organization] — [Month Year]                    │
├─────────────────────────────────────────────────────────────────────┤
│  VENDOR ASSESSMENT: 100%     ██████████████████████  Target: 100%  │
│  CONTRACT CLAUSES: 100%      ██████████████████████  Target: 100%  │
│  ACCEPTANCE PASS: 97%        ████████████████████░░  Target: 95%  │
│  ACCESS REVIEW: 100%       ██████████████████████  Target: 100%  │
│  VENDOR INCIDENTS: 0       ░░░░░░░░░░░░░░░░░░░░░░  Target: <1/y  │
│  VENDOR VULNS: 1/q         █░░░░░░░░░░░░░░░░░░░░░  Target: <2/q  │
│  COMPLIANCE SCORE: 86/100  ████████████████████░░  Target: >80   │
│  AUDIT FINDINGS: 2         ██░░░░░░░░░░░░░░░░░░░░  Target: <5/y  │
│  REMEDIATION SLA: 95%        ████████████████████░░  Target: 90%  │
│  OFFBOARDING: 100%         ██████████████████████  Target: 100%  │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "We Trust Our Vendor"

Symptom: Organization skips vendor assessment because "we've worked with them for years."

Reality: Long-term relationships can create complacency. Vendor security posture changes over time (turnover, new management, budget cuts, acquisitions).

Solution:

• Annual re-assessment of all vendors
• Continuous monitoring for security incidents and rating changes
• Don't let relationship duration override security due diligence
• Include security in contract renewals

Pitfall 2: "Security Clauses Are Boilerplate"

Symptom: Generic security clauses copied from internet templates without customization.

Reality: Boilerplate clauses may not address your specific risks, technology stack, or regulatory requirements. They may not be enforceable in your jurisdiction.

Solution:

• Customize security clauses for each engagement based on risk tier
• Have legal review security clauses for enforceability
• Include specific technical requirements (encryption standards, MFA, etc.)
• Reference specific compliance requirements (PCI DSS, DPDP Act, etc.)

Pitfall 3: "We Can't Find Secure Vendors"

Symptom: Organization accepts vendors with poor security because "all vendors are the same."

Reality: Vendor security varies significantly. Some vendors invest heavily in security; others treat it as a cost center. The difference is visible in certifications, tools, and processes.

Solution:

• Use vendor security ratings (BitSight, SecurityScorecard) as a screening tool
• Require minimum security standards (ISO 27001, SOC 2, or equivalent)
• Use vendor risk tiers to differentiate treatment
• Invest in vendor security improvement programs rather than accepting poor security

Pitfall 4: "Offboarding Is Just Access Revocation"

Symptom: Vendor offboarding only revokes access without complete data deletion, IP transfer, and knowledge transfer.

Reality: Incomplete offboarding creates lingering risks: data remnants, orphaned accounts, IP gaps, and operational continuity issues.

Solution:

• Use complete offboarding checklist
• Verify data deletion with evidence
• Update code escrow with final codebase
• Conduct knowledge transfer and document it
• Perform final security audit
• Close vendor relationship in vendor management system

Pitfall 5: "We Don't Need to Monitor Long-Term Vendors"

Symptom: Continuous monitoring is limited to the first year of engagement.

Reality: Vendor security posture degrades over time without oversight. Incidents, compliance changes, and personnel changes affect security continuously.

Solution:

• Annual security review for all vendors
• Continuous monitoring for critical/high-risk vendors
• Quarterly access review for all vendors with system access
• Incident monitoring (vendor breach notifications, security rating changes)
• Re-assessment when vendor has significant changes (acquisition, leadership change)

Pitfall 6: "Subcontracting Is the Vendor's Problem"

Symptom: Organization ignores subcontracting because "the vendor is responsible."

Reality: While the vendor is contractually responsible, the client bears the operational and reputational risk of subcontractor breaches. SolarWinds showed how supply chain attacks propagate.

Solution:

• Contractual control over subcontracting (approval required)
• Subcontractor security assessment
• Subcontractor liability clauses
• Right to audit subcontractors
• Monitoring of subcontractor activity

Pitfall 7: "Cost Overrides Security"

Symptom: Cheaper vendors are selected despite poor security posture.

Reality: The cost of a vendor breach (data breach, IP theft, regulatory fines, reputational damage) far exceeds the cost difference between a secure vendor and a cheap vendor.

Solution:

• Include security as a weighted factor in vendor selection (not just cost)
• Calculate overall value including security risk
• Use risk-adjusted pricing in vendor comparison
• Executive sponsorship for security-aware vendor selection

Pitfall 8: "Vendor Security Is Procurement's Job"

Symptom: Security team is not involved in vendor selection or management.

Reality: Procurement teams optimize for cost and delivery; security teams optimize for risk. Both must be involved.

Solution:

• Security team involvement in vendor selection (assessment, contract review)
• Security team involvement in acceptance testing
• Security team involvement in ongoing monitoring
• Cross-functional vendor management committee (procurement, security, legal, development)

Illustrative Scenarios

Hypothetical scenarios: composite examples for guidance, not real organisations or verified outcomes.

Scenario 1: E-commerce Platform With Five Development Vendors

Situation. An e-commerce company uses five development vendors. Contracts have no security clauses, vendors have broad repository access, one vendor has been testing with production customer data, and another has quietly subcontracted part of the work.

What applying 8.30 looks like.

1. Risk-tier each vendor; add a security addendum: right to audit, data handling, subcontracting approval, incident notice in hours, testing and delivery evidence.
2. Re-onboard vendor staff with NDAs, MFA and least-privilege repository access; client-controlled repositories only.
3. SAST, SCA and secret scanning on all vendor commits; security review for critical services.
4. Synthetic or masked test data only (A.8.33); subcontractors approved and assessed.
5. Quarterly vendor reviews and an annual audit of high-risk vendors.

Lesson. Most vendor failures come from what the contract never asked for. Write the requirements down, then check them.

Scenario 2: Bank Core-System Implementation

Situation. A bank's core-system vendor has an ISO 27001 certificate, but the contract lacks escrow, audit rights and subcontracting controls, and part of the work is being done by an offshore subcontractor the bank did not know about.

What applying 8.30 looks like.

1. Contract renegotiated under the RBI Master Direction on Outsourcing of IT Services (2023): audit rights, escrow, subcontracting approval, data location, incident notice, and testing obligations.
2. The certificate's scope checked against the services actually delivered.
3. A joint security governance forum; bank review of code for critical modules.
4. Independent penetration testing before go-live (by a CERT-In-empanelled auditor where required), with retests and sign-off.

Lesson. A supplier's certificate is a start, not proof. Check its scope and put the specific requirements into the contract.

Multi-Framework Mapping

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

PCI DSS v4.0.1 Mapping

DPDP Act 2023: Outsourcing Implications

OWASP SAMM Mapping

CIS Controls v8 Mapping

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI)

RACI Matrix for Outsourced Development Security

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

Role Descriptions

Documentation and Evidence Requirements

Recommended Documentation

ISO 27001 does not mandate specific documents for this control. If you select it, keep the documented information you need to show it is planned and working (clause 7.5), and set retention in your own retention schedule. Typical records:

Evidence for Audit

Continuous Improvement

Improvement Cycle

Plan → Implement → Measure → Review → Improve

Plan: Set targets for vendor assessment coverage, contract clause coverage, acceptance pass rate, incident rate.

Implement: Assess vendors, negotiate contracts, onboard securely, monitor, test deliverables, audit, offboard.

Measure: Track KPIs, conduct surveys, analyze audit results, monitor incidents.

Review: Quarterly vendor review, annual complete review, post-incident review, post-engagement review.

Improve: Update assessment questionnaire, refine contract templates, enhance monitoring, adopt new tools, improve training.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: Do we need to assess all vendors, or just critical ones?

A: All vendors should be assessed, but the depth varies by risk tier. Critical vendors get complete on-site assessments; low-risk vendors get lightweight questionnaire-based assessments. The key is that no vendor is "unassessed."

Q2: What if a vendor refuses to sign security clauses?

A: This is a red flag. If a vendor refuses basic security requirements (NDA, data handling, incident notification), consider alternative vendors. For critical vendors, you may need to accept enhanced monitoring and compensating controls, but this should be risk-accepted by the CISO.

Q3: How do we handle vendor code escrow?

A: Code escrow protects your IP if the vendor goes out of business or breaches contract. Use a third-party escrow agent (Iron Mountain, NCC Group, EscrowTech). Deposit source code, build instructions, and documentation. Verify escrow annually by performing a test build.

Q4: What is the difference between vendor assessment and vendor audit?

A: Vendor assessment is a questionnaire-based evaluation conducted before engagement. Vendor audit is an on-site or deep-dive examination of vendor controls, typically conducted annually or when concerns arise. Assessment is broader (all vendors); audit is deeper (critical vendors).

Q5: How do we monitor vendor security continuously?

A: Use security rating services (BitSight, SecurityScorecard) for continuous monitoring. Review vendor access logs monthly. Monitor vendor security news and breach notifications. Conduct quarterly security check-ins. Annual complete re-assessment.

Q6: What if our vendor is a large company with good security but poor execution on our project?

A: Large company security ≠ project security. The vendor may have good enterprise security but assign junior developers to your project with minimal oversight. Conduct project-specific security assessments, review code from your project specifically, and monitor project-level security practices.

Q7: How do we handle vendor security incidents?

A: Activate the incident notification clause immediately; start your own CERT-In 6-hour clock assessment. Require the vendor to provide a detailed incident report within 24 hours. Conduct joint investigation. Assess client impact. Require vendor to remediate root cause. Review contract penalties. Consider vendor termination for severe incidents.

Q8: Can we use the same security clauses for all vendors?

A: No. Security clauses should be risk-tiered. Critical vendors get extensive clauses (right-to-audit, code escrow, incident notification). Low-risk vendors get basic clauses (NDA, data handling). Customizing clauses increases enforceability and vendor acceptance.

Q9: How do we ensure vendor compliance with DPDP Act 2023?

A: Include DPDP Act compliance in contract clauses. Require vendor to process data only in India (or approved jurisdictions). Require data processing agreement. Require vendor to support data principal rights (access, correction, deletion, grievance). Require the vendor to notify you of suspected breaches within a few hours, so you can inform the Data Protection Board and affected people as the DPDP Rules require.

Q10: What about open source components in vendor deliverables?

A: Require SCA scanning in vendor CI/CD. Require vendor to provide SBoM with each deliverable. Include open source vulnerability patching in maintenance SLA. Require vendor to comply with open source licenses. Monitor for new CVEs affecting vendor dependencies.

Q11: How do we manage vendor access to our cloud environments?

A: Use cloud IAM with least privilege. Enable MFA for all vendor access. Use temporary credentials (AWS STS, Azure PIM). Monitor vendor access with cloud trail logs. Restrict vendor access to non-production environments. Require just-in-time access approval for production.

Q12: What is the role of procurement in vendor security?

A: Procurement should include security as a weighted evaluation criterion (not just cost). Procurement should use standard contract templates with security clauses. Procurement should not engage vendors without security assessment. Procurement should coordinate with security team on vendor selection.

Q13: How do we handle vendor security in Agile/Scrum engagements?

A: Include security acceptance criteria in sprint definitions of done. Require vendor security test reports per sprint for critical features. Conduct sprint security reviews. Include security retrospectives. Use automated SAST/SCA in shared CI/CD pipeline.

Q14: What if a vendor's country has sanctions or data access laws?

A: This is a geopolitical risk. Include contract jurisdiction clauses. Consider data localization (keep data in your country). Use encryption that you control (not vendor-controlled). Have backup vendors for critical functions. Monitor geopolitical developments. Consult legal counsel on sanctions compliance.

Q15: How do we measure vendor security effectiveness?

A: Track vendor-introduced vulnerabilities, vendor security incidents, vendor compliance scores, time to remediate vendor vulnerabilities, and cost of vendor security incidents. See Section 13 for a full KPI framework.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements. ISO, 2022.
2. ISO/IEC 27002:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Controls. ISO, 2022.
3. ISO/IEC 27036: Information technology, Security techniques, Information security for supplier relationships. ISO, 2014.
4. NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations. NIST, 2020.
5. NIST SP 800-161 Rev 1: Cybersecurity Supply Chain Risk Management Practices. NIST, 2022.
6. NIST CSF 2.0: Cybersecurity Framework. NIST, 2024.
7. PCI DSS v4.0: Payment Card Industry Data Security Standard. PCI SSC, 2022.
8. CIS Controls v8: Center for Internet Security, 2021.
9. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
10. BSIMM: Building Security In Maturity Model (use the latest edition). See also ISO/IEC 27036 (supplier relationships).

Supply Chain Security Resources

11. "Supply Chain Security: A Complete Guide": Various authors, NIST, 2022.
12. "The Software Supply Chain Security Handbook": Various, Linux Foundation, 2023.
13. SolarWinds Post-Incident Report: CISA, 2021.
14. CISA Supply Chain Risk Management: https://www.cisa.gov/supply-chain-risk-management
15. ENISA Supply Chain Security: https://www.enisa.europa.eu/topics/cybersecurity-policy/supply-chain-security

Contract and Legal Resources

16. Shared Assessments Standardized Information Gathering (SIG): https://sharedassessments.org/
17. ISO/IEC 27036-2: Supplier relationships, Requirements. ISO, 2014.
18. Cloud Security Alliance (CSA) STAR: https://cloudsecurityalliance.org/star/
19. SOC 2 Trust Services Criteria: AICPA, 2022.
20. ISAE 3402 / SSAE 18: Assurance reporting on service organizations.

Indian Regulatory Resources

21. Digital Personal Data Protection Act 2023: Government of India, 2023.
22. RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices: Reserve Bank of India, 7 November 2023 (in force from 1 April 2024); and RBI Cyber Security Framework in Banks: circular of 2 June 2016; and RBI Master Direction on Outsourcing of Information Technology Services, 10 April 2023.
23. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
24. IRDAI Guidelines on Information and Cybersecurity: Insurance Regulatory and Development Authority of India, 2023.
25. IT Act 2000 (as amended): Ministry of Electronics and Information Technology, India.
26. MeitY IT Outsourcing Guidelines: Ministry of Electronics and Information Technology, India.
27. DSCI Data Security Framework: Data Security Council of India, https://dsci.in
28. NASSCOM Security Guidelines: National Association of Software and Service Companies, https://nasscom.in

Industry Research

29. IBM Cost of a Data Breach Report 2024: IBM Security and Ponemon Institute, 2024.
30. Verizon Data Breach Investigations Report 2024: Verizon, 2024.
31. Copyright Act 1957, sections 17–19 (ownership and assignment), Government of India.
32. SolarWinds Supply Chain Attack Analysis: CISA, FireEye, 2021.