9.4.1. COTS, Open Source, and Managed Service Risk
💡 First Principle: Different software acquisition models create different risk profiles. COTS software gives you no visibility into source code but provides vendor support and contractual remedies. Open source gives you full visibility but requires you to monitor for vulnerabilities and apply patches yourself. SaaS transfers operational responsibility to the vendor but creates data custody and availability dependencies you cannot directly control.
Software acquisition risk comparison:
| Model | Source Code Visibility | Patch Responsibility | Customizability | Key Risk |
|---|---|---|---|---|
| COTS (Commercial) | None (proprietary) | Vendor provides; you deploy | Limited (configuration only) | Vendor patch timeliness; EOL risk; black-box vulnerabilities |
| Open Source | Full | Community provides; you integrate | Full (fork if needed) | Maintenance currency; abandoned projects; no SLA |
| SaaS | None | Vendor handles entirely | Configuration only | Data sovereignty; vendor lock-in; shared tenancy risk |
| Custom Development | Full (you wrote it) | You provide entirely | Full | Development quality; ongoing maintenance cost |
| Managed Service | Varies | Shared (provider handles infra) | Limited | Shared responsibility confusion; provider access to data |
Vendor security due diligence:
Before deploying third-party software in your environment, a structured assessment is required:
- Security questionnaire — Standardized questionnaires (SIG, CAIQ, VSA) assess the vendor's security program maturity across domains: access control, encryption, incident response, development practices, compliance certifications.
- Audit report review — SOC 2 Type II (operating effectiveness over time) is more valuable than Type I (point-in-time design). ISO 27001 certification demonstrates an ISMS. Review the audit opinion type and any qualifications.
- Penetration test results — Request recent penetration test reports or summaries. Understand the scope — a pentest of the vendor's corporate network does not assess their SaaS application's security.
- Data handling practices — Where is your data stored? Is it encrypted at rest and in transit? Who has access? What happens to your data on contract termination? Is multi-tenancy properly isolated?
- Incident response capability — Does the vendor have an IR plan? What is their notification timeline for security incidents affecting your data? Is there a contractual obligation to notify?
- Right-to-audit clause — Contractual provision allowing your organization (or a designated third party) to audit the vendor's security controls. Essential for critical vendors.
Contractual security requirements:
| Requirement | What It Protects |
|---|---|
| Data encryption at rest and in transit | Confidentiality of your data in vendor environment |
| Breach notification timeline | Your ability to meet your own regulatory notification obligations |
| Data retention and destruction upon termination | Your data doesn't persist in vendor systems after contract ends |
| Subprocessor notification | Awareness when vendor outsources to additional parties who access your data |
| SLA with security metrics | Measurable commitments to uptime, patch timelines, incident response |
| Right-to-audit | Independent verification that vendor meets contractual security obligations |
⚠️ Exam Trap: SaaS does not eliminate your security responsibility — it shifts the boundary. Under the shared responsibility model, the SaaS provider secures the application and infrastructure; you remain responsible for access management, data classification, user behavior, and regulatory compliance for the data you store in their service. A data breach caused by a misconfigured sharing setting in your SaaS application is your responsibility, not the vendor's.
Reflection Question: Your organization is evaluating two CRM platforms: one is a SaaS solution with SOC 2 Type II certification, the other is an on-premises COTS product. Both will process customer PII regulated under GDPR. Compare the security due diligence required for each option, identify the data protection risks unique to each model, and describe the contractual protections you would require for the SaaS option that are unnecessary for the COTS option.
