APO10: Managed Vendors

To meet the apo10: managed vendors requirement, you need a governed, end-to-end third-party (vendor) lifecycle that covers selection, due diligence, contracting, ongoing performance and risk monitoring, issue management, and exit. Operationalize APO10 by assigning clear ownership, defining repeatable procedures, and retaining evidence that management decisions and controls are performed as designed ¹.

Key takeaways:

• APO10 expects a controlled vendor lifecycle with documented roles, criteria, and decision records ².
• Auditors will ask for proof of operation: inventories, due diligence outputs, contracts, monitoring, and remediation evidence ³.
• The fastest path to readiness is mapping “who does what” plus evidence requirements to each vendor lifecycle stage.

APO10: Managed Vendors is the COBIT 2019 objective that pushes you from ad hoc vendor management to an auditable, risk-based operating model. For a Compliance Officer, CCO, or GRC lead, the practical requirement is straightforward: you must be able to show that third parties are identified, assessed, contracted with appropriate controls, monitored, and offboarded under defined governance, with records that demonstrate execution ¹.

This requirement page focuses on what you need to stand up quickly: the minimum set of decisions, workflows, and artifacts that make vendor risk management “real” under APO10. If you already have procurement and infosec processes, APO10 usually fails in the seams: incomplete inventory, inconsistent risk tiering, contracts that don’t match data flows, monitoring that exists only for critical vendors, and poor evidence retention. Your goal is to align stakeholders (Procurement, InfoSec, Legal, IT, Business Owners) under one lifecycle and one evidence standard, so you can answer exam questions with documentation instead of narratives.

Regulatory text

Framework excerpt (provided): “COBIT 2019 objective APO10 implementation expectation.” ¹

Operator interpretation: COBIT’s APO10 objective expects you to implement managed vendor practices as a defined governance capability, not an informal set of tasks. In practice, that means:

• You set ownership and decision authority for vendor risk and performance.
• You define a consistent lifecycle from onboarding to termination.
• You apply risk-based controls (more scrutiny for higher-risk vendors).
• You retain evidence that the process runs and issues are handled ¹.

Plain-English interpretation (what APO10 is asking for)

You must be able to prove, with artifacts, that your organization:

1. Knows which vendors/third parties it relies on (complete inventory).
2. Evaluates them before engagement (due diligence proportional to risk).
3. Contracts with them using requirements that match your risk posture and data exposure.
4. Monitors them during the relationship (performance, security/compliance signals, incidents, SLA failures).
5. Fixes problems with documented accountability and follow-up.
6. Exits cleanly (data return/destruction, access removal, transition planning).

If you cannot produce evidence across those stages, you will struggle to claim you “manage” vendors under APO10 ².

Who it applies to

Entity scope

• Any enterprise IT organization or business that relies on external vendors to deliver IT services, process data, support operations, or provide software and infrastructure ².

Operational scope (where APO10 shows up day to day)

APO10 applies whenever a third party:

• Accesses your systems or facilities
• Processes, stores, or transmits your data (including customer data)
• Delivers a technology service you depend on (SaaS, cloud, MSP, payroll, call center platforms)
• Develops code or runs operations that affect availability, integrity, or confidentiality

Treat “vendor” as the keyword framing, but run the program as third-party due diligence (TPDD) so you cover consultants, contractors, and service providers as well.

What you actually need to do (step-by-step)

The fastest operational model is a vendor lifecycle control map with clear RACI and evidence requirements at each stage.

Step 1: Assign ownership and governance

Do this:

• Name a control owner for vendor management (often GRC, Procurement, or a joint model).
• Define decision rights: who can approve high-risk vendors, accept residual risk, and approve exceptions.
• Establish minimum required checkpoints: inventory entry, risk tiering, due diligence completion, contract control review, go-live approval, periodic reviews, offboarding.

Artifacts:

• Vendor management policy/standard (owner, scope, authority)
• RACI matrix for onboarding, reviews, incidents, and offboarding
• Exception process and approval template

Step 2: Build and maintain a complete vendor inventory

Do this:

• Create a single system of record (spreadsheet is acceptable short-term if controlled).
• Capture: vendor legal name, service description, business owner, IT owner, data types, system access, subcontractors (if known), contract dates, renewal/termination terms, and risk tier.

Common hangup: teams confuse “vendors paid by AP” with “third parties that touch systems/data.” Your inventory needs both.

Artifacts:

• Vendor inventory export with required fields
• Data flow notes or service maps for higher-risk vendors
• Inventory governance procedure (who updates, when)

Step 3: Define risk tiering criteria and route work accordingly

Do this:

• Implement a tiering questionnaire or decision tree that classifies vendors by inherent risk (data sensitivity, access level, criticality, concentration risk, regulatory impact).
• Map each tier to required due diligence depth and approval authority.

Artifacts:

• Risk tiering methodology (criteria + rationale)
• Completed tiering records per vendor
• Approval evidence (ticket, sign-off, workflow log)

Step 4: Perform pre-contract due diligence (risk-based)

Do this:

• For low-risk vendors: confirm basic business details and confirm no system/data access.
• For medium/high-risk vendors: require security/privacy/compliance evidence appropriate to exposure (for example: security control summaries, incident response expectations, business continuity expectations, and any attestations your organization relies on).
• Document gaps and mitigations before signature.

Artifacts:

• Due diligence questionnaire and responses
• Reviews by InfoSec/Privacy/GRC (dated comments or approvals)
• Risk register entries for identified issues and compensating controls

Step 5: Contracting: embed required controls in the agreement

Do this:

• Create contract addenda or clause library tied to risk tier (security requirements, breach notification expectations, audit/assessment rights, subcontractor controls, data handling, access controls, termination assistance).
• Ensure the contract reflects reality: if the vendor has privileged access, the agreement must address that access explicitly.

Artifacts:

• Signed contract + security/privacy addendum (where applicable)
• Contract clause checklist mapped to tier
• Legal/Procurement approval trail

Step 6: Ongoing monitoring and performance management

Do this:

• Define what “monitoring” means per tier: SLA/KPI review cadence, security event reporting, attestations refresh, user access recertification for vendors with access, and issue tracking.
• Require business owners to attest periodically that the vendor is still needed and risk posture remains acceptable.

Artifacts:

• Monitoring logs (SLA reports, review minutes, tickets)
• Periodic review attestations (owner sign-off)
• Access review evidence for third-party accounts (where applicable)

Step 7: Issue management and remediation tracking

Do this:

• Centralize vendor issues (security findings, SLA misses, audit exceptions, incidents).
• Assign owners, due dates, and escalation paths.
• Record risk acceptance decisions when remediation is not feasible.

Artifacts:

• Vendor issue register with status and ownership
• Corrective action plans and closure evidence
• Residual risk acceptances with approver identity and date

Step 8: Offboarding and termination controls

Do this:

• Standardize offboarding: remove access, recover assets, confirm data return/destruction, transition services, and capture lessons learned.
• Trigger offboarding from contract end, vendor change, or service retirement.

Artifacts:

• Offboarding checklist completed and approved
• Access removal evidence (tickets, IAM logs)
• Data disposition confirmation (if applicable)

Required evidence and artifacts to retain (audit-ready checklist)

Use this as your minimum evidence pack for APO10:

• Policy/standard for vendor management and governance ²
• RACI and decision authority documentation
• Complete vendor inventory with tiering
• Due diligence records tied to each in-scope vendor
• Contract artifacts (signed agreements, addenda, clause checklists)
• Ongoing monitoring evidence (SLA/KPI reviews, security reviews, access reviews)
• Issue and exception tracking (including approvals)
• Offboarding evidence (access removal, data disposition where relevant)

The one control called out in your backend guidance is worth treating as non-negotiable: document control ownership, procedures, and evidence mapped to APO10. It is the shortest path to proving implementation ¹. Daydream can help by turning that mapping into a living control library with assigned owners and evidence requests that match your vendor tiers.

Common exam/audit questions and hangups

Expect auditors to press on these areas because they expose control design vs. operating effectiveness:

1. “Show me your complete vendor population.”
   Hangup: inventory omissions (shadow IT, departmental tools, unmanaged consultants).

2. “How do you decide which vendors are high risk?”
   Hangup: tiering exists but is inconsistently applied or not evidenced.

3. “Show me a sample onboarding from start to finish.”
   Hangup: due diligence performed after contract signing, or approvals missing.

4. “How do you monitor vendors after onboarding?”
   Hangup: monitoring is informal, handled in email, and not retained.

5. “What happens when a vendor fails an SLA or has an incident?”
   Hangup: no consistent issue register, no closure evidence, no escalation.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails APO10	Fix
Inventory equals “AP vendors only”	Misses SaaS and IT-managed third parties	Reconcile AP + SSO/SAML apps + contract repository + security tooling
Tiering is subjective	No repeatability	Use a decision tree with defined criteria and required fields
Due diligence after signature	No control at the point of commitment	Make “no due diligence, no go-live” a gating control
Contracts don’t reflect access/data	Requirements don’t match actual risk	Tie clause checklist to tier and data flow
Monitoring exists only in someone’s inbox	No evidence, no trend tracking	Store reviews, KPIs, and issues in a system of record
Offboarding is ignored	Access and data persist	Require an offboarding checklist and IAM/access removal evidence

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for APO10 specifically, so you should treat this as a framework conformance and audit-readiness requirement rather than a direct regulatory enforcement citation. The risk is still concrete: unmanaged vendors create security, availability, and compliance failures that become audit findings, customer assurance gaps, and incident drivers. APO10 reduces that exposure by forcing repeatable governance and evidence ².

Practical execution plan (30/60/90-day)

You asked for speed. This is an operator plan that prioritizes control evidence and lifecycle gates.

First 30 days (stabilize and define)

• Appoint APO10 control owner and publish RACI.
• Stand up the vendor inventory with required fields and an update process.
• Define risk tiers and approval authorities.
• Create an evidence map: for each lifecycle stage, list required artifacts and where they live.
• Pick your system of record (GRC tool, procurement platform, or controlled repository). If you use Daydream, configure APO10 ownership and evidence requests so you can collect artifacts consistently.

By 60 days (run it on real vendors)

• Backfill tiering for in-scope vendors starting with the highest-risk services.
• Implement onboarding gate: no production access until tiering, due diligence, and contract controls are complete.
• Launch monitoring for higher-risk vendors: SLA reviews, access reviews, and issue tracking.
• Start an exception workflow for vendors that cannot meet requirements, with documented risk acceptance.

By 90 days (prove operating effectiveness)

• Complete a sample-based “audit packet” for several vendors across tiers: onboarding through monitoring.
• Run an internal walkthrough with Procurement, InfoSec, and Legal to confirm the lifecycle works end-to-end.
• Validate offboarding by executing the checklist on at least one terminated vendor or a tabletop offboarding exercise, then retain evidence.
• Tighten documentation: procedures, templates, and evidence retention rules mapped to APO10 ³.

Frequently Asked Questions

Does APO10 apply to every vendor, even low-risk tools?

Apply APO10 to all third parties in inventory, then scale effort with risk tiering. Low-risk vendors still need a record, an owner, and a justification for lighter diligence.

What’s the minimum evidence auditors expect for APO10?

Auditors typically want inventory, tiering decisions, due diligence outputs, contract controls, monitoring records, and issue remediation evidence. If it isn’t retained and retrievable, it will not count as operating evidence ³.

Can Procurement “own” APO10, or does it have to sit in GRC?

Either model can work if decision rights, escalation, and evidence retention are explicit. The failure mode is split ownership with no single party accountable for lifecycle completeness.

How do we handle vendors that refuse our security addendum?

Treat it as an exception: document the gap, assess residual risk, identify compensating controls, and obtain written risk acceptance from the right approver. Track it to closure or renewal re-negotiation.

How should we handle subcontractors (fourth parties)?

Capture known subcontractors for higher-risk vendors and require contractual commitments around subcontractor controls where feasible. At minimum, document whether subcontractors are used and whether the vendor remains accountable.

We have multiple vendor lists across teams. Which one is the “real” inventory?

Pick one system of record and define reconciliation rules, then ingest other lists as sources. Control testing will focus on completeness and currency, not which department created the list.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview

3. OSA COBIT 2019 objective mapping