Guide

An example ITAM and CMDB process and policy.

A concise, adoptable framework you can lift into your own governance docs: the policy (what must be true) and the process (how you keep it true) for both IT Asset Management and the CMDB, plus the roles and cadences that make them hold. Each step maps to something Omnitam does on live, discovered data.

Accountability

Who owns what.

A policy without named owners is a wish. Assign these roles first; every process step below references them. R = responsible, A = accountable, C = consulted, I = informed.

ActivityITAM ManagerCMDB / Config ManagerAsset / Service OwnerPlatform / DiscoverySecurity
Discovery & intake of new resourcesIAIRC
Classification (asset vs CI, type)CACRI
Ownership assignmentARAII
License & entitlement reconciliationACRII
Relationship / dependency mappingIACRC
Recertification of ownership & accuracyARRIC
Drift detection & remediationCARRC
Retirement / disposalARRCC
Audit evidence & reportingARIIC
ITAM

IT Asset Management: policy and process.

The asset view answers "what do we own or pay for, who owns it, and are we compliant?" It is financial and contractual first, and it has a lifecycle.

Policy · what must be true

ITAM policy

  • Single source of truth. Every asset lives in one governed record, reconciled continuously against the real cloud. Spreadsheets are not a system of record.
  • Ownership is mandatory. No asset exists without a named owner and a cost center. Unowned assets are a finding, not a footnote.
  • Licenses are managed against assignments. Entitlements are recorded and compared to assigned seats. Over-assignment and unassigned seats are surfaced before a vendor audit or a renewal.
  • Every asset has a lifecycle state: requested, active, in-change, retired, disposed. State transitions are recorded, not implied.
  • Evidence is retained for up to seven years in write-protected, tamper-evident storage while you are a customer, and is exportable on demand for auditors and framework controls (SOX, ISO 27001, SOC 2). It can't be changed in normal operation; personal data can still be erased on request.
Process · how you keep it true

ITAM process

  1. Discover and intake. A read-only role in each account feeds continuous discovery. New resources appear in the record automatically; nothing is entered by hand.
  2. Classify. Each item is typed and marked as a financial asset or a configuration item (see CI vs Asset). Software titles are matched to a catalog.
  3. Assign ownership. Ownership rules and transfers make every asset chargeable to a team and a cost center.
  4. Reconcile entitlements. Recorded licenses are compared to assigned seats; true-up exposure and reclaim candidates are called out.
  5. Recertify. On a set cadence, owners confirm the asset, its owner, and its state are still correct. Exceptions are explicit and reviewed.
  6. Retire and dispose. Decommissioned resources move to retired, keep their history, and drop out of active counts and license consumption.
CMDB

Configuration management: policy and process.

The CMDB answers "what is running, how is it configured, and what does it depend on?" It is broader than the asset register: it includes the infrastructure a financial asset never captures, such as security groups, subnets, and route tables.

Policy · what must be true

CMDB policy

  • Discovered, not hand-entered. CIs are populated by discovery and reconciled against the live cloud, so the CMDB never silently rots between reviews.
  • A defined CI model. Every CI has a class, a unique identity, an owner, and a lifecycle state. Classes and their attributes are agreed, not ad hoc.
  • Relationships are first-class. Depends-on, runs-on, and member-of relationships are recorded so blast radius and impact are a query, not an investigation.
  • Accuracy has a standard. The CMDB is measured against discovery; a target accuracy and a maximum drift age are set, monitored, and reported.
  • Change is controlled and evidenced. Every change to a CI is written to a tamper-evident trail: who, what, when, and the value it replaced.
Process · how you keep it true

CMDB process

  1. Populate. Continuous discovery enumerates resources across every connected account and region into the CMDB.
  2. Classify. Each resource is mapped to a CI class and given a stable identity; assets are the subset that are also financially or contractually tracked.
  3. Map relationships. Dependencies are derived from the discovered configuration and kept current as the estate changes.
  4. Verify and reconcile. The record is compared to reality on the plan's scan cadence; unreconciled or stale CIs are flagged.
  5. Manage drift. Deviations between environments or from a baseline become ranked, owned, dated remediations, not folklore.
  6. Audit. Point-in-time state and a full change trail are exported on demand or on schedule as defensible evidence.
Cadence

How often each control runs.

Set these in policy and enforce them with automation. The suggested cadences below are a sensible default; tighten them for regulated estates.

ControlOwnerCadenceEvidence
Discovery scanPlatform / DiscoveryContinuous (near real-time on Standard+)Inventory snapshot
Ownership recertificationAsset / Service OwnerQuarterlySigned recert report
License / entitlement reconciliationITAM ManagerMonthly, and pre-renewalEffective license position
CMDB accuracy reviewCMDB / Config ManagerMonthlyDrift & reconciliation report
Environment parity / drift gatePlatformEvery releasePass/fail gate + findings
Certificate expiry reviewSecurityWeekly (alerted < 30 days)Certificate health report
Audit evidence exportITAM ManagerOn demand + scheduledCSV / JSON / PDF / XLSX

This is an example framework to adapt, not legal or compliance advice. Map each control to the specific obligations in your own regulatory scope, and have your risk and audit functions approve the final policy. Omnitam operationalizes the process side (discovery, classification, reconciliation, drift, evidence) on live data; the policy decisions remain yours.

Two related controls

Reconciliation vs. recertification.

Both keep the record honest, but they ask different questions, run on different clocks, and feed each other.

Upstream · data quality

Reconciliation

  • Question: does the record match what's actually running?
  • Unit: a duplicate-record cluster sharing a fingerprint (cloud ARN, certificate thumbprint, or license key), a discovery drop where a resource vanishes between sweeps, or an owner-reported finding.
  • Who acts: discovery detects; an owner or reviewer resolves the finding.
  • Cadence: continuous, as discovery runs and owners report a mismatch.
  • Output: a live view of duplicate clusters and discovery drops, drilling down to the affected records, plus owner-reported findings that stay open until resolved, with a resolution note and a mean-time-to-reconcile.
Downstream · ownership attestation

Recertification

  • Question: is this asset still owned, and is the assignment still correct?
  • Unit: one attestation task per asset; a duplicate cluster converges to one open task, not one per copy.
  • Who acts: the assigned certifier, usually the asset's owner, attests on a set cadence.
  • Cadence: scheduled (for example, quarterly), not continuous.
  • Output: a decision, confirmed, confirmed with changes, transfer, retire, or waived, plus any discrepancy the owner reports.
How they work together
  • A duplicate record or a data-source mismatch an owner reports during recertification becomes a reconciliation finding with its own resolve lifecycle, not just a note buried in one recert cycle.
  • Recertification is duplicate-aware: records sharing a fingerprint show their siblings alongside the attestation task, so an owner isn't asked to confirm the same asset once per copy.
  • Resolving a finding is tracked on reconciliation's own clock, independent of the recert cadence, so open/resolved counts and mean-time-to-reconcile reflect data quality directly.

Adopt the process, not just the policy.

A policy is only real when something enforces it. See the whole framework running on your own estate when trials open.

Discovered, not hand-entered Owned and recertified Up to 7-year tamper-evident evidence