Security+ Third-Party Risk, Privacy, Compliance, and Audits
Introduction
This lesson continues Domain 5, Security Program Management and Oversight (20% of SY0-701). It covers objective 5.3, explaining the processes associated with third-party risk assessment and management; objective 5.4, summarizing elements of effective security compliance; and objective 5.5, explaining types and purposes of audits and assessments. In the previous lesson you learned how an organization governs itself and treats its own risk. Now the focus moves outward and forward in time: the vendors whose failures become your incidents, the laws and contracts that define what "compliant" means, and the scoped assessments that provide evidence about control design and operation.
Modern organizations run on suppliers. A payroll processor holds employee data, a managed service provider holds administrator credentials, a software library sits inside every build. A supplier’s access or a compromised component can create an attack path regardless of the supplier’s size or budget. The exam therefore tests whether you can pick the right vendor-management document, choose the right type of audit or test, and explain what happens when compliance fails.
Learning objectives
After this lesson you will be able to:
- Describe vendor assessment methods: due diligence, penetration testing, right-to-audit clauses, and independent assessments.
- Explain vendor selection, including conflict of interest, and monitoring of vendors over time.
- Distinguish MOU, MOA, MSA, SLA, SOW, NDA, and BPA, and state when each is used.
- Use questionnaires and rules of engagement correctly.
- Describe compliance reporting, monitoring, and the consequences of non-compliance.
- Explain privacy concepts: legal implications, data subject rights, and ownership of data.
- Distinguish internal and external audits, attestation, and the three kinds of penetration testing environments.
- Select reconnaissance types (passive, active) and describe a test's rules of engagement.
1. Third-party risk management
Third-party risk is the risk that a supplier, partner, contractor, or service provider causes loss to your organization through its own weaknesses. Your data, your customers, and your reputation remain your responsibility even when a vendor holds them. Regulators generally say the same: you can outsource a task, but you cannot outsource accountability.
Vendor assessment
Before and during a relationship the organization gathers evidence about the vendor's security. Common methods include:
- Due diligence: the investigation done before signing, covering the vendor's financial health, security program, certifications, incident history, and references.
- Questionnaires: structured lists of security questions the vendor answers in writing (for example, Do you encrypt data at rest? Do you run annual penetration tests? How quickly do you notify customers of a breach?). Standard questionnaires exist so vendors can reuse answers. Questionnaires are self-reported, so they are weaker evidence than independent testing.
- Independent assessments: third-party audit reports, such as SOC 2 reports or ISO/IEC 27001 certificates, which provide external assurance.
- Penetration testing: either the vendor shares recent test results, or the contract permits the customer to test the connection or service, within agreed rules of engagement.
- Right-to-audit clause: contract language that lets the customer, or an appointed auditor, inspect the vendor's controls, records, and facilities. Define scope, notice, confidentiality, evidence access, and limits explicitly. Statutory audit/information rights may also apply; the absence of a clause does not itself establish that no legal right exists.
- Supply chain analysis: understanding the vendor's own suppliers (fourth parties), because risk flows downstream.
- Evidence of security: policies, vulnerability management metrics, business continuity tests, and insurance coverage.
A good assessment is proportional. A vendor that prints marketing brochures needs far less scrutiny than one that hosts customer payment data. Organizations commonly tier vendors by data sensitivity and business criticality, then apply deeper assessment to higher tiers.
Vendor selection and conflict of interest
Selection should be documented and objective: requirements, scoring criteria, and evaluation of several candidates. A conflict of interest occurs when someone involved in the decision has a personal or financial stake in a particular outcome, such as a procurement manager whose relative owns the bidding company. Conflicts undermine fair selection and can create legal and ethical exposure. The remedy is disclosure, recusal of the conflicted person, and independent review.
Selection also considers whether the vendor can meet legal requirements (data residency, breach notification), operational needs (support hours, scalability), and exit options (can you retrieve your data if the relationship ends?).
Vendor monitoring
Trust is not permanent. Vendor monitoring repeats the assessment on a schedule and when something changes: annual questionnaire refreshes, review of new audit reports, tracking of vendor breaches and news, performance review against the SLA, and continuous external scoring of the vendor's internet-facing posture. Findings feed the risk register from the previous lesson. When a vendor repeatedly fails, the organization escalates, applies contractual remedies, or exits.
The relationship also ends. Offboarding a vendor means revoking accounts and network connections, returning or deleting data under the agreement, and documenting verification. Address backups, legal retention/holds, subprocessors, and any delayed deletion schedule; a certificate alone does not establish that every copy vanished.
Example 1: choosing a managed backup provider
A 400-employee clinic network needs an offsite backup provider. Three candidates respond. The security team:
- Classifies the service as high risk because backups contain patient records.
- Sends a standard questionnaire to each vendor and requires a current SOC 2 Type II report.
- Checks that the contract includes a right-to-audit clause, prompt initial breach notification that supports applicable legal deadlines, with updates as facts emerge, encryption with customer-managed keys, and data return and deletion at exit.
- Discovers that the procurement lead's brother is a shareholder in Vendor B. The lead is recused and a second reviewer re-scores the bids.
- Schedules annual reassessment and monthly SLA review.
Each step maps to a tested concept: tiering, evidence, contract clauses, conflict of interest, and monitoring.
Record vendor findings in the risk register and treatment process with named owners and review dates.
2. Agreement types
CompTIA expects you to recognize the main agreements and their purpose.
| Agreement | Full name | Purpose and key points |
|---|---|---|
| SLA | Service-level agreement | Measurable service commitments (uptime, response time, recovery time) and any agreed credits, remedies, or escalation for misses |
| MSA | Master service agreement | Umbrella contract with general terms; later work orders refer to it, so terms need not be renegotiated each time |
| SOW | Statement of work | Defines a specific project: scope, deliverables, schedule, and cost |
| MOA | Memorandum of agreement | Records responsibilities and agreed commitments; legal effect depends on content and applicable law |
| MOU | Memorandum of understanding | Expresses shared intent and general responsibilities; often non-binding and less detailed than a contract |
| NDA | Non-disclosure agreement | Sets confidentiality duties, permitted use, exclusions, and duration |
| BPA | Business partners agreement | Defines how partners share profits, losses, responsibilities, and decision making |
| Work order / task order | Work order | Specific task issued under an MSA |
Using the agreements together
A typical enterprise purchase uses several. The MSA sets legal terms (liability, confidentiality, termination). A SOW describes a migration project. An SLA sets uptime and incident response times. An NDA protects confidential material exchanged during the project. Security requirements, such as breach notification, minimum encryption, background checks, and the right to audit, belong in the contract or its security addendum, so responsibilities are explicit rather than inferred from marketing claims.
Remember that an SLA addresses availability and performance by default. If the question asks where to state that the vendor must report a breach within 24 hours, the best answer is the contract or security addendum, not a general MOU.
Legal effect depends on the text, context, and applicable law, not the acronym alone. For the exam, an MOU commonly expresses shared non-binding intent; obtain appropriate review for actual commitments. Review cloud shared responsibility and architecture boundaries when allocating provider and customer duties.
Rules of engagement
Rules of engagement (ROE) define what a tester or assessor may do: which systems are in scope, which techniques are allowed, testing windows, who to contact in an emergency, how to handle sensitive data found, and when to stop. The ROE defines operational boundaries; it does not replace valid authorization from the relevant owners or third-party service policies. A penetration test without written authorization and ROE is indistinguishable from an attack and may be illegal. The ROE is also relevant to vendor relationships: a customer who wants to test a cloud provider's service must follow the provider's testing policy.
3. Security compliance
Compliance means meeting the requirements set by laws, regulations, industry standards, contracts, and internal policy. Compliance is not the same as security: a compliant organization can still be breached, and a secure organization can still fail an audit if it cannot show evidence. Mature programs aim for security and prove it with compliance evidence.
Compliance reporting
Compliance reporting communicates the state of compliance to the right audience.
- Internal reporting goes to management, the board, risk committees, and audit committees. It includes control test results, open findings, exceptions, and remediation progress.
- External reporting goes to regulators, customers, and certification bodies. Examples include breach notifications, annual attestations, and filings required by law.
Effective reports use consistent metrics, state the scope and the date, link findings to owners and due dates, and distinguish compliant, partially compliant, and non-compliant conditions.
Consequences of non-compliance
The exam lists several consequences and expects you to match them to scenarios.
| Consequence | Example |
|---|---|
| Fines | A regulator penalizes a company for failing to protect personal data |
| Sanctions | Restrictions on business activity or a license suspended |
| Reputational damage | Customers lose trust after a public enforcement action |
| Loss of license | A professional or operating license revoked |
| Contractual impacts | A partner terminates a contract, or a payment processor imposes penalties or stops processing cards |
| Legal action | Lawsuits from affected individuals |
Contractual consequences are easy to forget. A merchant that fails to meet the payment card industry standard can face higher fees, mandatory assessments, or loss of the ability to accept cards, even if no law was broken.
Compliance monitoring
Compliance monitoring continuously checks that controls operate as required. It has four themes.
- Due diligence and due care: due diligence is investigation and evaluation before and during a relationship; due care concerns reasonable protective action. “Investigate versus protect” is a useful exam mnemonic, not a complete legal definition or a strict before/after boundary.
- Attestation and acknowledgement: staff, vendors, and managers formally confirm that they follow policy (for example, annually signing the acceptable use policy). Attestation is also used by auditors and executives to confirm statements about controls.
- Internal and external monitoring: internal teams test controls with scripts, scans, and reviews; external parties such as auditors and regulators provide independent views.
- Automation: tools collect evidence automatically (configuration drift, patch status, access reviews), reducing manual effort and supporting period-based evidence. Verify collection coverage and gaps; automated logs do not by themselves prove that every control operated continuously.
4. Privacy
Privacy concerns how personal data is collected, used, shared, retained, and deleted. Security protects confidentiality, integrity, and availability; privacy also addresses the legitimacy, purpose, necessity, and effects of processing. Security+ treats privacy as part of compliance.
Legal implications
Privacy laws vary by geography. They are commonly described at four levels:
- Local and regional: for example, state laws in the United States.
- National: a country's data protection law.
- Global: laws with extraterritorial reach, such as the EU General Data Protection Regulation (GDPR). Its scope includes processing in the context of an EU establishment and certain non-EU processing that offers goods/services to people in the Union or monitors their behavior there. Citizenship or EU residency alone is not the test.
- Sector-specific: healthcare and finance rules.
Common obligations, depending on the applicable regime, include a lawful basis (consent is one possible basis), purpose limitation, data minimization, security safeguards, breach notification, limits on cross-border transfers, and retention limits. Failure leads to the consequences in the previous section.
Data subject rights and roles
The data subject is the individual; the controller decides why and how data is processed; the processor acts on the controller's behalf. Typical rights include the right to be informed, to access their data, to correct it, to have it erased in some circumstances, to restrict or object to processing, and to receive data in a portable format. Under GDPR, access generally includes confirmation, a copy of personal data being processed, and required contextual information, rather than an unrestricted dump of every document. Verify identity proportionately and protect others’ rights. Respond without undue delay and normally within one month; an allowed complexity/volume extension requires timely notice and reasons. Other regimes have different rules.
Privacy controls
Controls that support privacy include data minimization, anonymization or pseudonymization, tokenization, masking, encryption, retention schedules, consent management, and privacy impact assessments. Pseudonymized data can still be linked back to a person with additional information, so privacy law often treats it as personal data. Under GDPR, data that is effectively anonymous is outside personal-data scope; assess reidentification risk rather than relying on an “anonymous” label.
Coordinate notification and evidence preservation with the incident response and investigation workflow.
5. Audits and assessments
An audit compares reality with a defined standard and reports the result. An assessment evaluates and often recommends improvements. Both produce evidence for decision makers.
Attestation
Attestation is a formal statement by a qualified party that something is true, such as a service auditor's report that a provider's controls were suitably designed and operated effectively. In the SOC family, a Type I report examines the design of controls at a point in time, and a Type II report examines whether they operated effectively over a period (commonly six to twelve months). For operating effectiveness over time, Type II supplies additional evidence within its stated scope and period. Read the opinion, exceptions, covered services, subservice treatment, and required customer controls; neither type is a guarantee of security. Customers use these reports when assessing vendors. Attestation can also be internal, for example when an executive confirms that a control owner has reviewed access rights.
Internal audits
Internal audits are performed by the organization's own audit function. To be credible, the internal audit team reports to the audit committee or board rather than to the managers being audited. Internal audits can evaluate compliance and control effectiveness and report to the audit committee. A control-owner self-assessment is a separate form of evidence, not automatically an independent internal audit. A self-assessment is performed by the control owners themselves; it is useful and cheap but less independent.
Internal audits are good for preparing for external audits, finding gaps early, and sustaining improvement. A weak audit result can lead to corrective action plans, management accountability, additional controls, and budget decisions.
External audits
External audits are performed by independent parties: regulators, certification bodies, and external audit firms. They are required for some regulations and certifications, and customers often demand them. They provide independence and credibility but cost more and can be disruptive. Types include:
- Regulatory examinations: a regulator checks compliance with law.
- Independent third-party audits: for certification or customer assurance, such as ISO/IEC 27001 certification or a SOC 2 report.
- Customer audits: authorized by the right-to-audit clause.
Penetration testing
A penetration test is an authorized, simulated attack to find and exploit weaknesses and show their real impact. It differs from a vulnerability scan: a scan lists potential weaknesses; a penetration test attempts to chain them, proves exploitability, and reports business impact.
Environments, often named by the tester's prior knowledge:
| Type | Knowledge given to testers | Notes |
|---|---|---|
| Unknown environment (black box) | Minimal inside information beyond authorized scope | Tests discovery and outside attack paths within time and scope limits |
| Partially known environment (gray box) | Some information such as a user account or network diagram | Balances realism and efficiency |
| Known environment (white box) | Extensive information such as source code and architecture | Can improve coverage efficiency; depth still depends on scope, skills, and time |
The exam may use the older names (black, gray, white) or the newer ones (unknown, partially known, known). Learn both.
Related terms:
- Reconnaissance: passive reconnaissance gathers information without interacting with the target (public records, search engines, social media, third-party historical DNS data, certificate transparency datasets); active reconnaissance interacts with the target (port scans, probing services) and can be detected.
- Offensive and defensive exercises: red team attacks, blue team defends, purple team combines the two to share lessons, and white team referees and controls the exercise.
- Physical penetration testing checks locks, badges, cameras, tailgating resistance, and guards.
- Integrated testing combines technical, physical, and social techniques.
- Continuous testing runs automated and recurring testing rather than only an annual snapshot.
- Bug bounty programs invite external researchers to find vulnerabilities under published rules, paying rewards for valid reports.
The test must follow rules of engagement. After testing, a report details findings, evidence, severity, and remediation guidance; the organization tracks fixes in the risk register and retests.
Worked example: which assessment fits?
Scenario. A company hosts a customer portal. Its largest customer asks for assurance that the controls protecting its data actually work over time, not just on paper. The company also wants to know whether an outside attacker with no inside information could reach the database. The security manager has a limited budget this year.
Step 1: identify the two needs. The customer needs independent, ongoing assurance about controls. The company needs to know if a real attacker could succeed.
Step 2: match tools. For assurance over time, an independent attestation report covering a period (SOC 2 Type II) is the best fit; a Type I report addresses design and implementation at a specified date rather than operating effectiveness over the requested period, and a self-assessment lacks independence. For attacker realism with no inside information, an unknown-environment penetration test fits.
Step 3: set boundaries. Write ROE that name the portal and its hosting accounts, allowed techniques, a testing window, emergency contacts, and a rule that any real customer data found must not be copied.
Step 4: why other choices are weaker. A vulnerability scan alone shows potential weaknesses but does not prove exploitation. A known-environment test can improve coverage efficiency, but this scenario specifically asks for an outside attacker’s initial knowledge. An internal audit is not independent enough for the customer.
Solution. Obtain a SOC 2 Type II report and commission an unknown-environment penetration test under written rules of engagement.
6. Comparison tables
Match vendor evidence to the assurance question
| Evidence | Main use | Important limit |
|---|---|---|
| Marketing claims | Initial information | Not independent verification |
| Self-completed questionnaire | Structured vendor responses | Verify material claims with evidence |
| Policies and documents | Declared design and responsibilities | Do not alone establish operating effectiveness |
| Independent certificate or Type I report | Scoped assurance at defined dates | Certification scope and SOC reporting objectives differ |
| SOC 2 Type II | Operating-effectiveness evidence for a period | Read opinion, exceptions, and customer responsibilities |
| Customer-authorized penetration test | Exploit-path evidence within ROE | A limited test does not cover every governance control |
Audit types
| Audit | Performed by | Independence | Typical purpose |
|---|---|---|---|
| Self-assessment | Control owners | Low | Readiness, continuous improvement |
| Internal audit | Organization's audit team | Depends on reporting line and objectivity | Check policy and control effectiveness |
| External audit | Independent firm or regulator | Assess independence, competence, and scope | Certification, legal requirement, customer assurance |
7. Common pitfalls
- Confusing due diligence (investigating before) with due care (acting responsibly continuously).
- Assuming a signed questionnaire proves security. It is self-reported.
- Treating an SLA as the place for all security terms. Put breach notification, audit rights, and encryption requirements in the contract or security addendum.
- Choosing a MOU when a binding commitment is required. MOUs often express intent only.
- Selecting an internal audit when the question asks for independent assurance for customers or regulators.
- Mixing up SOC 2 Type I (design at a point in time) and Type II (operation over a period).
- Confusing vulnerability scanning with penetration testing.
- Starting a test without written authorization and rules of engagement.
- Forgetting that the data controller remains accountable when the processor causes a breach.
- Thinking compliance equals security. Passing an audit does not guarantee safety.
8. Exam tips
- Exam tip: if the scenario says "contract with vendor," look for the document type: ongoing service levels means SLA; overall terms means MSA; one project means SOW; confidentiality means NDA; shared intent without a binding contract means MOU.
- Exam tip: "ability to inspect the vendor's controls" points to a right-to-audit clause.
- Exam tip: "no knowledge of the environment" is unknown environment (black box). "Provided credentials and diagrams" is partially known (gray box). "Source code and full documentation" is known (white box).
- Exam tip: "gather information without touching the target" is passive reconnaissance; "scan ports" is active.
- Exam tip: "independent confirmation over a period of time" suggests a Type II attestation or an external audit.
- Exam tip: a question about the consequence of failing an internal audit usually expects corrective action, management accountability, or remediation planning, and a question about failing a regulatory requirement expects fines, sanctions, or loss of license.
- Exam tip: when choosing between a reasonable and a drastic response, choose the proportionate one. Assess severity, recurrence, dependencies, and contractual rights. An isolated minor SLA miss usually calls for proportionate corrective action; a critical failure can warrant urgent escalation.
9. Mini case study
Situation. Northwind Health, an EU-established hospital group with 6,000 employees, outsources its patient-portal hosting to CloudCare. CloudCare's sales team provided a completed questionnaire claiming "industry-leading security." Northwind's contract with CloudCare has an SLA for 99.9% availability but no breach-notification term and no audit rights. Three months after launch, CloudCare discovers that a misconfigured storage bucket exposed appointment records for two weeks. CloudCare tells Northwind eleven days after discovery. Northwind's privacy officer finds that the records belong to EU residents. Northwind's regulator opens an inquiry, and the largest insurer partner demands evidence of Northwind's vendor oversight.
Questions.
- What weaknesses existed in Northwind's vendor management process?
- Which contract changes should Northwind make?
- Who is accountable to the regulator and the individuals?
- Which assessments should Northwind perform to restore confidence?
Commented solution.
- Northwind relied on a self-reported questionnaire and did not obtain independent evidence such as a SOC 2 Type II report. The contract lacked a right-to-audit clause and a breach-notification term. The SLA described only availability, not the needed security terms. Review monitoring and reassessment evidence rather than assuming an oversight program existed merely because the vendor was onboarded.
- Add a security addendum requiring initial notification without undue delay, timely updates, and cooperation with applicable notification duties, encryption and configuration requirements, a right-to-audit clause, annual penetration test evidence, data return and deletion at exit, and financial remedies. Keep the SLA for availability and add incident response times.
- Northwind, as the data controller, remains accountable to the regulator and to the data subjects. CloudCare, as processor, has contractual and legal duties but does not remove Northwind's responsibility. GDPR applies here through Northwind’s EU establishment. The processor must notify the controller without undue delay after awareness. The controller must assess notification: notify the competent authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to people. Communicate to affected people without undue delay when high-risk criteria are met, subject to applicable exceptions. Document the assessment, including a decision not to notify.
- Request CloudCare's independent attestation, run a targeted external penetration test and configuration review under written ROE, conduct an on-site or remote audit using the new right-to-audit clause, and add continuous monitoring. Record the risk in the register, assign an owner, and report the results to the board and insurer.
Key terms
- Third-party risk: risk arising from suppliers, partners, and service providers.
- Due diligence / due care: investigate before acting; maintain reasonable protection continuously.
- Right-to-audit clause: contract term allowing inspection of a vendor.
- Questionnaire: structured written vendor security survey.
- Conflict of interest: personal stake that may bias a decision.
- SLA, MSA, SOW, MOA, MOU, NDA, BPA: common agreement types.
- Rules of engagement: written limits and permissions for a test.
- Compliance reporting: communicating compliance status internally and externally.
- Attestation: formal statement that controls exist or operated effectively.
- SOC 2 Type I / Type II: design at a point in time / operation over a period.
- Internal / external audit: audit by the organization's team / by an independent party.
- Penetration test: authorized simulated attack to exploit weaknesses.
- Known, partially known, unknown environment: white, gray, and black box testing.
- Passive / active reconnaissance: collect information without / with touching the target.
- Data subject, controller, processor: privacy roles.
- Bug bounty: rewards for responsibly reported vulnerabilities.
Summary checklist
- I can describe vendor assessment, selection, conflict of interest, and monitoring.
- I can match SLA, MSA, SOW, MOA, MOU, NDA, and BPA to their purposes.
- I can explain questionnaires, right-to-audit clauses, and rules of engagement.
- I can describe compliance reporting, monitoring, and the consequences of non-compliance.
- I can explain privacy obligations, data subject rights, and the controller-processor relationship.
- I can distinguish internal audits, external audits, and attestation, including SOC 2 Type I and II.
- I can choose between unknown, partially known, and known environment penetration tests.
- I can differentiate passive and active reconnaissance and a scan from a penetration test.
Sources
-
CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 5.3–5.5.
-
NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices: https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final (opens in a new tab)
-
NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final (opens in a new tab)
-
GDPR text (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2016/679/oj (opens in a new tab)
-
PCI Security Standards Council documents: https://www.pcisecuritystandards.org/document_library/ (opens in a new tab)
-
EDPB: breach documentation and notification (opens in a new tab)
