BAI09: Managed Assets

BAI09 in COBIT 2019 focuses on asset management as a governance control, not a tooling project. For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate BAI09 into a small set of verifiable operational outcomes: you can identify assets, you know who owns them, you control changes, and you can show records that prove it happened.

Most teams “have a CMDB” or “have spreadsheets,” but fail BAI09 in practice because the inventory is incomplete, ownership is unclear, or lifecycle events (new assets, transfers, retirements) do not consistently update the system of record. Auditors then treat the asset list as unreliable, and every downstream control gets questioned: vulnerability management scope, patching coverage, incident response, access reviews, backups, and third-party risk scoping.

This page gives requirement-level implementation guidance you can execute quickly: who the requirement applies to, what to build (process and artifacts), what evidence to keep, typical exam questions, and common failure modes. It also includes a practical 30/60/90-day plan you can run as a GRC workstream, with day-to-day responsibilities assigned to IT and Security control owners.

Regulatory text

Provided excerpt: “COBIT 2019 objective BAI09 implementation expectation.” ¹

Operator interpretation of what you must do:
To meet the BAI09: Managed Assets objective, you must implement and maintain an auditable asset management capability. That means:

• Defined asset classes and scope (what counts as an asset for your enterprise).
• Assigned accountability (business and technical ownership).
• A maintained inventory/system of record with minimum required fields.
• Lifecycle controls for onboarding, change, and retirement/disposal.
• Operating evidence that the process runs (reviews, reconciliations, exceptions).
  ¹

Plain-English interpretation (what “Managed Assets” means in practice)

“Managed” means you can answer these questions without scrambling:

1. What assets do we have? Endpoints, servers, cloud resources, network devices, applications, databases, and other in-scope technology.
2. Who is responsible for each asset? Someone accountable for risk decisions and someone accountable for technical operation.
3. Where is the authoritative record? One system of record (or a governed federation) with defined data quality rules.
4. What changes and when? New assets are recorded, changes are tracked, and retired assets are removed/marked and handled securely.
5. How do we know it’s accurate? Reconciliations and periodic reviews exist, exceptions are documented, and drift is corrected.
   ¹

Who it applies to (entity and operational context)

Applies to: Enterprise IT organizations implementing COBIT 2019 governance and management objectives. ¹

Operational contexts where BAI09 becomes audit-critical:

• Hybrid environments (on-prem + multiple clouds) where ownership and inventory drift quickly.
• M&A, rapid provisioning, or high contractor usage where assets appear outside standard procurement.
• Regulated operations where downstream controls depend on asset scope (security monitoring, patching, access).
  ¹

Primary stakeholders you need aligned:

• IT Operations (endpoint/server/network), Cloud Platform teams, Application owners
• Security (vulnerability management, SOC, IAM)
• Procurement/Finance (purchase and depreciation records often reveal “unknown” assets)
• GRC (control design, evidence, testing)

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

Use this as a build sheet. Keep it small enough to execute, strict enough to audit.

1) Define asset scope and classes (write it down)

Create an “Asset Scope Standard” that specifies:

• Asset classes: endpoints, servers, network gear, virtual machines, containers, cloud services/accounts/projects, applications, databases, security tooling, and “shadow IT” discovery expectations.
• In-scope vs out-of-scope criteria (test labs, employee-owned devices, discontinued products).
• The system(s) of record and the tie-breaker rule if multiple inventories exist.
  Artifact: Asset Management Standard (v1), approved by IT/Security leadership.

2) Define ownership and RACI at the record level

For each asset class, define:

• Business owner (risk acceptance, funding priority).
• Technical owner (operations, patching, configuration).
• Custodian/operator (day-to-day queue handling).
• GRC control owner for BAI09 evidence collection.

Minimum expectation: every asset record has an accountable owner or a documented exception workflow.
Artifacts: RACI matrix; owner assignment procedure; exception form.

3) Set minimum asset record fields (your “definition of done”)

Standardize required fields per asset class. Example minimum set:

• Unique asset ID, hostname/resource ID, environment, location/region
• Owner(s), support group, criticality tier, data classification
• Lifecycle status (planned/active/suspended/retired)
• Build source (procured, imaged, cloud template), and last verified date

Do not overdesign. Pick fields you can actually keep current.
Artifacts: Data dictionary for asset records; required-field validation rules.

4) Establish lifecycle controls (acquire → change → retire)

Document procedures that force asset inventory updates at key events:

• Onboarding: Procurement intake, imaging, cloud provisioning, app onboarding. Require record creation before production use (or within a defined operational window you set internally).
• Change: Ownership transfer, re-hosting, re-IPing, major configuration changes. Tie to change management tickets where possible.
• Retirement/Disposal: Decommission request, approval, secure wipe, license reclaim, record closure.
  Artifacts: Lifecycle SOPs; ticket templates; decommission checklist.

5) Implement reconciliation and drift management

Auditors look for proof the inventory is trustworthy.

• Reconcile inventory against at least one independent source per asset class (examples: endpoint management, cloud provider inventory, network scans, procurement lists).
• Log exceptions: unknown assets found, owner missing, duplicates, retired assets still active.
• Track remediation to closure and record the reason for any accepted exceptions.
  Artifacts: Reconciliation reports; exception register; remediation tickets.

6) Build an evidence-ready review cadence and reporting

Define a repeatable review process that produces artifacts:

• “Asset inventory review” meeting notes or sign-offs
• KPI-style summaries (counts by class, exceptions open/closed) without inventing precision you can’t defend
• Sampling results (spot checks of owner accuracy and lifecycle status)

This is where many programs fail: the process exists but nobody can show it ran.
Artifacts: Review calendar; meeting minutes; sign-off records; sample testing worksheets.

7) Map the control and evidence to BAI09 for exam readiness

Create a one-page control statement and evidence map:

• Control objective (BAI09 aligned)
• Control owner(s)
• Systems used
• Evidence generated, where stored, retention period (your internal decision)
• How testing is performed (GRC sampling approach)

Daydream fit (earned mention): If you struggle to keep evidence consistent across teams, Daydream can act as the control workspace where you assign owners, collect reconciliations and review sign-offs, and keep an audit-ready evidence packet mapped to BAI09. This directly supports the recommended control of documenting ownership, procedures, and evidence mapped to BAI09. ¹

Required evidence and artifacts to retain (audit packet checklist)

Keep these in a single folder structure by period (month/quarter) and asset class:

• Asset Management Standard + lifecycle SOPs (current, approved versions)
• Asset class scope statement and data dictionary
• RACI and named owners (not roles only)
• System of record screenshots/config exports showing required fields and workflows
• Reconciliation outputs and exception register (with closure evidence)
• Change/decommission ticket samples showing inventory updates
• Periodic review artifacts (sign-offs, minutes, sample testing results)
• Training/communications to IT teams on how to onboard/retire assets (as applicable)

Common exam/audit questions and hangups

Expect these, and pre-answer them in your evidence packet:

1. “What is your authoritative asset inventory?” If you name multiple tools, explain governance and conflict resolution.
2. “How do you ensure completeness?” Show reconciliations against independent sources.
3. “Who owns assets and who approves exceptions?” Provide RACI and examples of ownership assignment.
4. “How do you handle cloud ephemerality?” Show how you track accounts/projects, tags, and lifecycle state.
5. “Show me a retired asset.” Auditors love decommission evidence: secure wipe, access removal, record closure.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating asset management as “CMDB equals compliance.”
  Fix: Define minimum fields, reconciliation, and lifecycle triggers. A tool without operating proof fails BAI09.

• Mistake: Ownership is a mailbox or a team name only.
  Fix: Require a named accountable owner for high-impact assets; allow team ownership only with documented on-call responsibility.

• Mistake: Ignoring SaaS and applications.
  Fix: Include application and SaaS inventories in scope, even if ownership is initially imperfect. Track exceptions rather than pretending they are out of scope.

• Mistake: No exception handling path.
  Fix: Create an exception register with reason, risk note, approver, and remediation date (your internal decision).

• Mistake: Reconciliation happens, but nothing closes.
  Fix: Tie findings to tickets with due dates and escalation rules.

Risk implications (why auditors care)

If your asset inventory is unreliable, you cannot credibly claim security coverage. Vulnerability scanning, patch SLAs, EDR coverage, logging, backup scope, and even third-party connection inventories become disputable. That typically expands audit sampling, drives repeat findings, and forces compensating controls that cost time and attention. ¹

Practical 30/60/90-day execution plan

No fixed-duration promises; use this as phased execution.

First 30 days (stabilize and define)

• Name the BAI09 control owner and asset-class operational owners.
• Publish Asset Management Standard (scope, classes, systems of record).
• Define minimum required fields and the owner assignment rule.
• Stand up the evidence folder structure and templates (recon report, exception register, review sign-off).

Days 31–60 (operate the control for real)

• Implement lifecycle SOPs with ticket templates for onboarding and retirement.
• Run first reconciliations for top asset classes (endpoints, servers, cloud accounts/projects).
• Start exception intake and remediation workflow; escalate unknown assets.
• Run the first periodic review and store artifacts.

Days 61–90 (make it audit-ready and resilient)

• Expand reconciliation coverage to remaining asset classes (apps/SaaS, network devices, databases as applicable).
• Perform GRC sampling: verify ownership accuracy and lifecycle status on a sample across classes.
• Finalize the one-page BAI09 control narrative and evidence map.
• Schedule recurring reviews and define how you measure drift (qualitatively if metrics are immature).

Frequently Asked Questions

What counts as an “asset” for BAI09?

Any technology component you rely on to deliver services or process data should be evaluated for inclusion: endpoints, servers, cloud resources, applications, databases, and key SaaS. The key is to define your scope explicitly and keep it consistent with how Security and IT operate. ¹

Can we have multiple asset inventories (CMDB + cloud inventory + endpoint tool)?

Yes, but you must name the system of record per asset class and document how conflicts resolve. Auditors will challenge “many sources, no authority” more than “one imperfect source with reconciliation.” ¹

How do we handle ephemeral cloud assets that appear and disappear quickly?

Track higher-level constructs (accounts/projects/subscriptions) and require tagging/ownership inheritance so short-lived resources still map to an owner and environment. Keep reconciliation evidence that shows you detect unmanaged resources and drive remediation. ¹

Do we need a formal disposal and secure wipe process to satisfy BAI09?

If you retire hardware or decommission systems, you need a defined retirement workflow and evidence that it happened. Secure wipe and access removal are common retirement steps because they prevent residual data exposure and orphaned access. ¹

What evidence is most persuasive in an audit?

Reviewable operating records: reconciliation outputs, exception register entries with closure tickets, and lifecycle tickets that show inventory updates. Pair those with approved procedures and a clear ownership model. ¹

We’re missing owners for a chunk of assets. What’s the least-bad approach?

Create an exception workflow that assigns interim technical ownership to the responsible IT group, then forces business owner assignment for high-impact assets. Track progress transparently and show auditors you can identify and remediate unknown ownership. ¹

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping