APO13: Managed Security

APO13 in COBIT 2019 is where security stops being a collection of tools and becomes a managed capability with defined outcomes, assigned decision rights, and measurable execution. For a Compliance Officer, CCO, or GRC lead, the challenge is rarely “do we have security controls?” The challenge is “can we show the controls are governed, consistently run, and aligned to enterprise objectives, with evidence that stands up to audit?”

This page gives requirement-level implementation guidance for the apo13: managed security requirement, written to help you stand up or tighten the governance and evidence layer quickly. You’ll translate the objective into a small set of operational commitments, assign accountable owners, and create an evidence pack that is easy to maintain. Where COBIT remains high-level, you’ll anchor execution in common enterprise security program mechanics: policies and standards, risk-based control selection, security monitoring, incident management integration, and third-party security expectations.

Sources used here are limited to the COBIT framework overview published by ISACA and an objective mapping reference from Open Security Architecture. ¹

Regulatory text

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

Operator interpretation (what you must do):
You must be able to demonstrate that information security is managed: security direction is defined, responsibilities are assigned, policies and supporting procedures exist, controls are implemented across the environment, and leadership can monitor security performance and risk. The “implementation expectation” language means auditors will look for both design (documents, governance) and operation (recurring execution evidence), not only a one-time program launch. ²

Plain-English interpretation of the requirement

APO13 expects a security program that you can run on a schedule, measure, and improve. Practically, that means:

• Someone is accountable for the security program and can make decisions.
• Security requirements are documented (policy/standards) and integrated into IT delivery and operations.
• Controls exist and are maintained (technical and administrative).
• You can prove it with artifacts produced through normal work, not “audit-only” spreadsheets.
• Exceptions are handled deliberately, with risk acceptance and expiry.

This is “managed security,” not “security tasks.”

Who it applies to (entity and operational context)

Applies to: Enterprise IT organizations using COBIT 2019 as a governance framework. ²

Where it bites operationally:

• Regulated organizations aligning IT controls to a governance framework for audits and examinations.
• Any environment with material reliance on third parties (cloud/SaaS, managed services) where security outcomes depend on external control operation.
• Organizations with distributed IT (multiple product teams, multiple infrastructure stacks) where security consistency requires clear standards and accountability.

CCO/GRC ownership reality: You often won’t “run” security operations, but you own the governance and evidence layer: RACI, policy lifecycle, control mapping, attestation workflows, and audit readiness.

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

1) Define scope and outcomes for “managed security”

• Write a one-page APO13 scope statement: which business units, systems, data types, and third parties are in scope.
• Define security outcomes in operator terms: confidentiality/integrity/availability objectives, regulatory drivers, and business-aligned risk tolerance statements.
• Identify “crown jewels” and map them to control intensity (higher scrutiny, tighter change control, stronger monitoring).

Deliverable: APO13 scope & outcomes doc, approved by security and a business executive sponsor.

2) Assign decision rights and accountable ownership (RACI you can defend)

• Name an APO13 Control Owner (usually CISO or Head of Security).
• Assign operational owners for key sub-domains: security engineering, IAM, vulnerability management, incident response, third-party security, and security awareness.
• Define escalation paths and governance forums (security steering committee or equivalent) with clear agendas: risk decisions, exceptions, metrics,重大 incidents.

Tip: If ownership is “IT” or “Security Team” without a named role, auditors treat it as unowned.

Deliverable: APO13 RACI + governance charter.

3) Build the security policy stack and link it to controls

Create a structured hierarchy:

• Information Security Policy (executive-level principles and required behaviors)
• Standards (minimum requirements: access control, encryption, logging, secure configuration, SDLC)
• Procedures / runbooks (how the work is done)
• Control statements mapped to APO13 and to your internal control library

Keep the policy language enforceable: use “must” for requirements, “should” for guidance, and define exception handling.

Deliverable: Approved policy/standards set with version control and review cadence.

4) Map APO13 to your operating controls (the “control map”)

Build a table that connects:

• APO13 expectation → control objective → control owner → frequency → evidence produced → systems/tools involved

Example control objectives that typically satisfy “managed” expectations:

• Security risk assessment and acceptance process
• Identity lifecycle controls and privileged access governance
• Vulnerability identification, remediation tracking, and exception workflow
• Security monitoring/logging expectations and alert handling
• Incident response integration and post-incident review loop
• Third-party security requirements and onboarding reviews

Deliverable: APO13 control map (the single most useful audit artifact).

5) Operationalize monitoring and metrics (prove it runs)

Pick a small set of metrics tied to control operation and risk. Avoid vanity metrics; choose measures that trigger action:

• Exception counts and aging (policy, vulnerability, access)
• Coverage indicators (systems onboarded to logging, endpoint management, vulnerability scanning)
• Control execution health (review completion, stale privileged accounts)
• Incident trends and corrective action closure

Set thresholds that create decisions, then document what happens when you breach a threshold.

Deliverable: Security metrics pack + recurring review meeting notes with actions.

6) Integrate security into change and delivery

APO13 fails in practice when security is separate from IT delivery.

• Embed security requirements into change management (e.g., approval gates for high-risk changes).
• Require security sign-off criteria for system go-live (logging enabled, baseline hardening, access model defined).
• Ensure exceptions are recorded with business ownership and expiry.

Deliverable: Documented gates/checklists; evidence from change tickets.

7) Build an evidence retention plan (design evidence that appears naturally)

Create an “evidence register” aligned to your control map. For each control, define:

• What proof looks like (report, ticket, minutes, screenshot, configuration export)
• Where it lives (GRC tool, ticketing system, SIEM, document repository)
• Who produces it and who reviews it
• How long you retain it (align to your audit and legal retention rules)

Daydream fit (earned mention): Daydream can hold the APO13 control map, assign owners, track control operation attestations, and centralize evidence links so audit prep becomes a status review instead of a document chase.

Required evidence and artifacts to retain

Use this as a minimum evidence pack for the apo13: managed security requirement:

1. Governance

• Security program charter, steering committee terms, meeting agendas/minutes
• RACI with named roles and escalation paths

2. Policy and lifecycle

• Information Security Policy and supporting standards
• Policy exceptions register with approvals and expiry
• Policy review approvals and version history

3. Control operation evidence

• Access reviews (who approved, what changed, completion sign-off)
• Privileged access inventory and review evidence
• Vulnerability management reports with remediation tracking and exceptions
• Logging/SIEM onboarding lists and alert handling evidence
• Incident tickets, post-incident reviews, corrective action tracking

4. Risk management integration

• Security risk assessments (system, project, or enterprise)
• Risk acceptance records and compensating controls
• Control testing or assurance results and follow-up actions

5. Third-party alignment (where applicable)

• Third-party security requirements (contract clauses or security addendum references)
• Third-party onboarding/periodic review artifacts (questionnaires, SOC reports, issue remediation tracking)

Common exam/audit questions and hangups

Typical questions

• Who is accountable for security governance, and where is that documented?
• Show your security policy stack and how you enforce standards.
• How do you know controls operate consistently across business units and third parties?
• Where are exceptions tracked, and who can approve them?
• Provide evidence for a sample period that key controls ran as scheduled.
• How do metrics drive decisions? Show meeting outputs and remediation actions.

Hangups that slow audits

• Evidence scattered across systems with no index.
• Controls described at a high level but no proof of recurring operation.
• Security standards exist but are not embedded into change/project delivery.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating APO13 as “have a security policy.”
   Fix: Build the control map and evidence register first, then align policies to those controls.

2. Mistake: No clear owner for exceptions.
   Fix: Require business owner approval for risk acceptance, set expiry dates, and track compensating controls.

3. Mistake: Metrics that don’t cause action.
   Fix: Tie each metric to a decision (escalate, fund remediation, restrict access, pause go-live).

4. Mistake: Control testing is informal and not retained.
   Fix: Use lightweight attestations and periodic reviews, then store results in a central system.

5. Mistake: Third-party security is out of scope by assumption.
   Fix: Explicitly define which third parties are in scope and what proof you require from them.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for APO13 specifically, and COBIT is a framework rather than a regulator. Your practical risk is indirect: if you align to COBIT and claim maturity against APO13, auditors and customers will test whether your program is actually managed. The most common failure mode is evidentiary: controls may exist, but you cannot prove consistent operation or accountable governance. ²

Practical 30/60/90-day execution plan

Constraint: This plan uses phases, not day counts with implied effort, because implementation time depends on scope and resourcing.

First 30 days (stabilize governance and proof)

• Appoint APO13 accountable owner and approve RACI.
• Draft and approve the APO13 scope & outcomes statement.
• Build the APO13 control map (v1) and an evidence register (v1).
• Identify top evidence gaps and assign owners with deadlines.
• Stand up a recurring security governance meeting with minutes and action tracking.

By 60 days (make controls repeatable)

• Finalize policy/standards hierarchy and publish it with an exception process.
• Integrate security checks into change/go-live workflows for in-scope systems.
• Define the metrics pack and run at least one formal review with documented decisions.
• Start periodic control attestations (access reviews, vulnerability exceptions, logging onboarding).

By 90 days (prove operating effectiveness)

• Produce an “audit-ready” evidence bundle for a sample period from real operations.
• Run an internal walkthrough: pick one critical system, trace from policy requirement to control operation to evidence.
• Close high-risk gaps or document compensating controls and approved exceptions.
• Implement a steady-state cadence for evidence capture in your GRC system (Daydream or equivalent) so the next audit is a pull, not a scramble.

Frequently Asked Questions

What does “managed” mean in the apo13: managed security requirement?

It means security is governed with accountable ownership, defined policies and standards, and recurring control operation you can prove with evidence. Auditors will test both design and operation, not only documentation. ²

Can we satisfy APO13 if we outsource most security operations to a third party?

Yes, if you retain governance, define requirements, monitor performance, and keep evidence that the third party meets your controls. You still need ownership, metrics, and exception handling inside your organization.

What is the fastest evidence pack to assemble for APO13?

Start with the APO13 control map and an evidence register, then collect a sample period of artifacts: policy approvals, access review sign-offs, vulnerability tracking, incident records, and governance minutes. Index everything so an auditor can follow the trail.

How do we map APO13 to other frameworks we already use?

Use your existing control library (ISO 27001, NIST CSF, SOC 2) as the control layer and map APO13 to it as the governance objective. OSA’s COBIT mappings can help as a reference point for crosswalk thinking. ³

Who should approve security risk acceptances and policy exceptions?

The business owner who accepts the risk should approve, with security providing analysis and recommended compensating controls. Track expiry dates and re-approval triggers so exceptions do not become permanent.

What will auditors flag first under APO13?

Unclear accountability, missing recurring evidence that controls ran, and exceptions without documented business approval. Evidence scattered across tools without an index is another frequent finding.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview

3. OSA COBIT 2019 objective mapping