Field guide

Certifications

Six certifications come up most often around this kit's three areas — portfolio, AI, and access. This states what each one actually covers and ties it to a task the kit's tools already do. It isn't a study guide, and it isn't a recommendation to sit any particular exam.

Or download everything as one package: all visuals (ZIP).

Standards and frameworks

This kit's crosswalk explorer maps each of its 29 control themes to ISO/IEC 19770, COBIT 2019, ISO/IEC 27001, and ISO/IEC 42001. This section explains what each of those actually is, and how they relate to one another — the explorer is where you see the exact clause-by-clause mapping.

Glossary

Plain-English definitions for terms used across this kit's methods, tied to a Halden Logistics example wherever one exists in the demo data.

ITAM (IT Asset Management)

The overall discipline of knowing what IT assets an organization has and managing them through their lifecycle. Halden example: every method in this kit — rationalization, access review, AI intake — is a slice of ITAM applied to Halden's estate.

SAM (Software Asset Management)

The software-specific slice of ITAM: licensing, entitlements, and compliance. Halden example: the license checks in rationalization against licenses.csv are SAM work.

HAM (Hardware Asset Management)

The physical-device slice of ITAM: acquisition, deployment, maintenance, refresh, and retirement of hardware. Halden example: Halden's laptop and device refresh cycle is tracked by the hardware-lifecycle tool — see the CHAMP section above.

APM (Application Portfolio Management)

Deciding what to keep, replace, consolidate, or retire across an application estate. Halden example: the rationalization tool's tolerate/invest/migrate/eliminate call between Clausebase and Tallysheet.

CMDB (Configuration Management Database)

A system of record for IT assets and how they relate to one another. Halden example: apps.csv and licenses.csv function as a lightweight CMDB extract for the demo estate.

Entitlement

The specific usage right a license grants — not just the fact that software is installed. Halden example: Payflow's license entitlements don't match its 748 users, an open license-position question the rationalization run flags as unverified.

Effective license position (ELP)

The gap between what's licensed (entitlements) and what's actually deployed or used. Halden example: comparing Payflow's licensed entitlements to its real user count before a vendor audit.

True-up

Paying for usage that exceeded licensed entitlement, usually settled at renewal or after an audit. Halden example: if Payflow's usage is found to exceed its entitlement, Halden owes a true-up at the next renewal.

Reconciliation

Matching what's deployed or in use against what's licensed or recorded, to surface the gap. Halden example: matching accounts.csv logins against employees.csv to find orphaned accounts is the same reconciliation logic applied to access instead of licenses.

Normalization

Cleaning inconsistent product or vendor names so the same thing isn't counted twice under different labels. Halden example: Clausebase and Tallysheet are both normalized to "contract management," not left as two unrelated names.

SWID tag (software identification tag)

A machine-readable file that identifies an installed software product, defined in ISO/IEC 19770-2. Halden example: none of Halden's demo apps ship SWID tags, so today's inventory work is manual.

Shelfware

Licensed or purchased software sitting mostly or entirely unused. Halden example: Pulseboard carries 350 entitlements against only 45 users — a shelfware candidate the rationalization run flags.

TIME model

The tolerate/invest/migrate/eliminate categorization used to decide an application's fate. Halden example: Northbeam ERP is tolerated as-is; Clausebase is eliminated in favor of the cheaper, functionally equal Tallysheet.

Orphaned account

An active account with no valid current owner, most often a leaver's account that was never disabled. Halden example: ACC-063, still active 37 days after EMP-072's termination date.

Access certification (access review)

A periodic check that every account's access is still valid, owned, and appropriately scoped. Halden example: the review that surfaced ACC-063, ACC-104, and seven privileged admin accounts needing owner re-approval.

Segregation of duties (SoD)

Making sure no one person holds two roles that together let them create and approve the same transaction unchecked. Halden example: SoD wasn't tested in the sample review because no SoD rules had been supplied to check against — a named gap, not a clean result.

Risk tier

A category — such as minimal, limited, or high-risk — assigned to a system or use case that determines which controls apply. Halden example: AI-004, the HR candidate-shortlisting tool, tiers as high-risk; the email spam filter (AI-001) tiers as minimal.

AI inventory

The AI-system equivalent of a software inventory: one record per use case, with purpose, data, and risk tier. Halden example: each of Halden's six AI systems gets one row once ai-intake runs.

Prohibited practice

An AI use explicitly barred by law regardless of risk tier — for example certain manipulation or social-scoring uses. Halden example: ai-intake's step 3 rules this out, or escalates to legal, before tiering continues for any of Halden's six systems.

Human-in-the-loop

A person reviews, or can override, an automated decision before or after it takes effect. Halden example: AI-002's invoice field extraction has a person review the fields; AI-001's spam quarantine does not — itself a finding, since nothing releases quarantined mail automatically either.

Chargeback / showback

Allocating (chargeback) or simply reporting (showback) IT cost to the business unit that incurs it. Halden example: neither is possible with Halden's current data — no app in apps.csv carries a cost-center field yet.

Vendor management

Tracking supplier relationships, contract terms, and renewal or termination notice periods. Halden example: the rationalization run can't finalize an eliminate decision for Clausebase because no vendor contract terms were supplied.

Governance council (steering committee)

A standing body with named authority to approve, reject, or set policy for software or AI decisions. Halden example: the draft Halden Software Governance Council, reviewed by program-setup and found to have no sponsor or written decision rights yet.

Decision rights

A written statement of who decides what, and at what threshold, so intake doesn't default to "everything goes to committee." Halden example: the council's draft charter names a cost-or-risk threshold but never sets it, leaving the triage owner nothing to check requests against.

Sponsor

The executive who holds budget authority and gives a governance body the power to actually act. Halden example: the council review's central finding — no sponsor is named anywhere in the draft charter.

Escalation path

A named route, and person, for resolving disputes a governance body can't settle itself. Halden example: the Halden council escalates disputes to the COO, who sits outside the council and breaks ties.

Recertification

The requirement to periodically retest, or re-earn continuing-education credit, to keep a professional certification active. Annual for CAMP, CSAM, and CHAMP; a multi-year continuing-education cycle for AIGP — see the Certifications section above.

Privileged access

An account with elevated rights — typically admin — that can change configuration or data beyond an ordinary user's reach. Halden example: seven admin-role accounts in the sample review, each routed back to its app owner for re-approval.

Dormant account

An account with no recent login activity — a distinct access-review finding from an orphaned one, which is about ownership rather than activity. Halden example: zero were found in the most recent export, though the review flags that the export window is too short to call this conclusive.

Data provenance

Where a system's data actually came from — necessary to know before its privacy or quality risk can be judged. Halden example: ai-intake's step 2 records this for each of the six AI systems; several aren't stated by the source CSV alone and are marked unverified.

Risk register

A running, owned log of identified risks and their treatment, rather than a one-time note. Halden example: AI-004's high-risk tiering gets a risk-register entry with HR as the named owner.

Application governance vs. data governance

These two disciplines get used interchangeably, but they ask different questions and are usually owned by different people. Application governance manages the software: what applications exist, who owns each one, what they cost, how they're licensed, who has access to them, and when they get retired — the subject of this whole kit. Data governance manages the information inside those applications: what each data element means, who's accountable for its quality and stewardship, how sensitive it is, how long it has to be kept, and what privacy law says about it. This kit doesn't build that discipline out — the comparison below exists so the boundary is clear, and so the four places the two disciplines meet don't get missed.

Where they meet

Retiring an application is a data decision, not just a software one. Before an app is eliminated, someone has to decide what happens to the data it holds — archive it, migrate it, or delete it — and that decision needs a data owner's sign-off, not just an IT one. Halden example: the rationalization checklist's retirement step requires exactly this before any eliminate decision is executed; it isn't optional cleanup.

Data sensitivity sets access-review priority. Which accounts get reviewed first should follow how sensitive the underlying data is, not just an alphabetical or convenient order. Halden example: the access review deliberately checked the 10 confidential apps before the 50 internal ones, and two of the three orphaned accounts it found were on confidential systems.

AI systems are only as trustworthy as the data behind them. An AI system's risk tier and its controls both depend on what data it uses, where that data came from, and whether it includes personal data. Halden example: ai-intake's step 2 records data used, personal-data status, and provenance for each of Halden's six systems before any tier is assigned.

Asset records are themselves data, and need the same quality discipline. An inventory that's wrong — missing owners, mismatched user counts, stale entitlements — isn't just an ITAM problem; it's a data-quality problem inside the ITAM system. Halden example: the crosswalk's data-quality-of-asset-records theme, and the itam-maturity check's evidence-per-area step, both treat the accuracy of the asset data itself as something to verify, not assume.

A full data classification and retention tool is planned for phase 2 of this kit; today, these four intersection points are handled inside the existing tools rather than by a dedicated one.

Practicum

Seven hands-on exercises, all built around Halden Logistics and the same demo data referenced throughout this field guide. Each one has you work a real governance problem by hand with only a checklist, then check your own answer on the interactive practicum page — no installs, no AI shortcuts, and no one grading over your shoulder. They're grouped by the certifications above: program setup and ITAM maturity for CAMP, crosswalk mapping, rationalization, and access review for CSAM, hardware lifecycle for CHAMP, and AI intake for AIGP.

Start with the practicum overview, which lists all seven exercises in order and explains how the self-checking practicum page works, or jump straight to the interactive practicum page.