Agreements, and monitoring a vendor after the ink dries

Objective 5.3 in this course covers third-party risk. The previous lesson took assessment and selection; this one takes the agreements and the ongoing monitoring from CompTIA's scope note. It is the applied lab for 5.3.

Why this matters

The agreement acronyms — SLA, MOU, MOA, MSA, SOW, NDA, BPA — are a near-certain exam item, and they are pure recall. Learn seven short definitions and the marks are yours.

The monitoring half matters for a different reason: vendor risk is assessed thoroughly once, at selection, and then usually never again. The vendor's security three years later is not the security you assessed, and nothing in the process notices unless somebody built the noticing.

The lesson

SLA, MOA, MOU, MSA, WO/SOW, NDA and BPA, and what each is for

The seven, with the distinguishing feature of each:

• SLA (service level agreement) — defines the measurable service levels the provider commits to: uptime, response times, resolution times, and the remedies if they are missed. Security-relevant SLAs include incident notification timeframes, patching deadlines and support availability. If a question mentions a performance or availability commitment with consequences, it is an SLA.
• MOU (memorandum of understanding) — a statement of intent between parties describing a shared understanding. Generally not legally binding, and used where parties want to record an intention before, or instead of, a contract.
• MOA (memorandum of agreement) — a step firmer than an MOU: it records agreed roles, responsibilities and commitments, and it is normally intended to be binding, though it is usually less detailed than a full contract.
• MSA (master service agreement) — the umbrella contract setting out the standard terms — liability, confidentiality, security requirements, dispute resolution — once, so that individual pieces of work do not renegotiate them each time.
• SOW / WO (statement of work / work order) — the specific deliverables, timeline, milestones and price for a particular piece of work, executed under an MSA. MSA sets the terms; SOW says what is being done this time.
• NDA (non-disclosure agreement) — obliges the parties to protect confidential information disclosed to them. Mutual or one-way. It is what makes it safe to share architecture, findings or incident detail with a third party, and it is typically signed before any meaningful assessment happens.
• BPA (business partnership agreement) — governs a partnership: each party's contribution, how decisions are made, how profits and liabilities are shared, and how the partnership ends.

The two distinctions the exam most often tests: MOU is non-binding intent, MOA is agreed commitment; and MSA is the standing terms, SOW is this particular job.

Security clauses worth knowing as things that belong in these documents: incident notification within a stated period, the right to audit, approved sub-processors, data location and handling, encryption requirements, data return and destruction at termination, and liability for a breach.

The service level that is measured versus the one that is promised

An SLA is only a control if the levels are measured and enforced, and this is where they usually fail.

Three gaps the exam rewards recognising:

• Nobody measures it. The SLA promises 99.9% availability and nobody computes it, so the vendor self-reports and the number is whatever their monitoring says. Independent measurement — your own synthetic checks — is what makes the commitment real.
• The definition is favourable. Availability excluding planned maintenance, measured monthly rather than annually, on the vendor's definition of "down", can be met while your users had a bad month. Read what is excluded.
• The remedy is trivial. Many SLAs' penalty is a service credit worth a few percent of one month's fee — which is not remotely proportionate to an outage that stopped your business. Service credits are not compensation and should not be relied on as risk transfer.

The security-specific levels to insist on: incident notification within a stated number of hours, because your own regulatory clock starts when the breach occurs and not when the vendor gets round to telling you; patching timeframes for critical vulnerabilities; and support response for security issues specifically, rather than the general queue.

Ongoing monitoring, and the review cadence that is written down

Vendor monitoring is continuing to check after selection. CompTIA lists it explicitly because the one-time assessment is the norm and it is insufficient.

What changes after you sign: the vendor is acquired, changes sub-processors, moves hosting to another region, loses the staff who built the controls, has an incident, lets a certification lapse, or quietly changes what the product does with your data.

What monitoring looks like in practice:

• a scheduled reassessment, with a cadence proportional to risk — annually for critical vendors, longer for minor ones — and it is written into the contract and the calendar, because otherwise it does not happen;
• certification currency — certificates expire, and an expired ISO certificate or a SOC 2 report covering a period that ended eighteen months ago is not current evidence;
• incident notification actually arriving, and being handled by your own IR process from Domain 4;
• news and threat intelligence on the vendor, including whether they appear in breach reporting;
• performance against the SLA, measured by you;
• and change notification — being told about sub-processor changes, regional moves and material changes to the service.

Two things make this work: a vendor inventory that records who each vendor is, what data and access they have, their criticality, their contract dates and their next review — the asset management discipline from Domain 4 applied to suppliers; and a named owner per vendor, in the business, who is accountable for the relationship. An unowned vendor is an unmonitored vendor.

Offboarding a vendor, and the access that outlives the contract

Vendor termination is the mirror of the decommissioning problem from Domain 4, and it fails the same way: the contract ends and the access does not.

What a complete vendor offboarding covers:

• Access revoked — every account, API key, certificate, VPN credential and federated trust. Including accounts created during the engagement that are not in the original list.
• Data returned and destroyed. The contract should specify the format, the timeframe, and require certification of destruction — the same evidence standard as physical media in Domain 4. Remember their backups, which typically outlive the deletion of the live data, and get a stated timeframe for those too.
• Integrations removed — webhooks, connectors, OAuth grants, inbound allow-list entries, DNS records pointing at their infrastructure. An OAuth grant to a decommissioned SaaS product is a standing authorisation nobody reviews.
• Knowledge transfer and documentation, so the function can be operated or migrated.
• Inventory updated, so the vendor is recorded as terminated rather than silently absent.

The termination clause matters and belongs in the agreement from the start: what notice is required, what happens to the data, how long they retain it, what transition assistance they owe, and — the one people omit — what happens if the vendor terminates, or fails. A supplier going into administration is a continuity event, and the BIA from 5.2 should have identified which vendors are single points of failure.

Choosing the right agreement type for a described relationship

The exam's shape is a described relationship and the right instrument. A decision aid:

Two habits for the harder variants. When two options both fit, ask what the document is for: the SLA is about performance levels, the SOW about what work, the MSA about terms. And when the scenario stresses that something is not legally binding, that is MOU almost every time — it is the only one on the list whose defining feature is non-enforceability.

A closing connection to Domain 2: everything in these two lessons exists because a supply chain attack passes every technical control. You cannot patch a supplier, and you cannot detect a correctly signed malicious update from a vendor you trust. What you can do is choose carefully, write down what they owe you, limit what they can reach, check that it is still true, and be able to remove them completely. That is the whole of third-party risk management, and it is why it lives in the governance domain rather than the operations one.

What to take into the exam

• MOU is non-binding intent; MOA records agreed, binding commitments.
• MSA is the standing terms, SOW is this particular job under them.
• An SLA is only a control if you measure it yourself and the remedy is proportionate; service credits are not risk transfer.
• Insist on a stated incident-notification timeframe — your regulatory clock starts at the breach, not at the phone call.
• Reassessment cadence must be contractual and calendared, or it will not happen; every vendor needs a named business owner.
• Offboarding covers accounts, keys, OAuth grants, integrations, DNS, their backups, and certified data destruction.