IAM0.7 Your IAM Program Package

What the program package is

The IAM program package is the cumulative deliverable across all fifteen modules. It's not a configuration export or a settings checklist. It's the documented reasoning, operational cadences, risk register, compliance evidence, and executive communication that turn a collection of identity configurations into an operational program.

Most tenants have configurations. Few have a program. The difference is that a program answers three questions a configuration can't: why is identity governed this way (ADRs), what happens on what schedule (governance cadences), and what risk remains after the governance is in place (risk register). The capstone in Module 14 assembles all five components, reviews them for coherence, and tests them through three simulated stakeholder challenges — CISO, IT Director, and Audit.

Estimated time: 30 minutes.

Five components

Component 1 — Architecture Decision Records (ADRs)

Every significant design decision in the course is documented as an ADR. The format is consistent across all modules:

• Context: What problem are you solving? What constraints exist — licensing, hybrid environment, HR system gaps, organizational politics, data quality?
• Decision: What did you decide? Why this approach over alternatives?
• Consequences: What does this enable? What does it break? What residual risk remains?
• Communication: How do you explain this to a CISO in 30 seconds?

You write your first ADRs in IAM1.7 (the governance state assessment). By Module 14, you'll have 20 or more ADRs covering every governance domain — provisioning source selection, group architecture strategy, entitlement management design, access review scope and cadence, privileged access model, non-human identity governance, delegation boundaries, and monitoring thresholds.

The ADR portfolio is the most transferable artifact in the package. You can take the ADR format and the decision reasoning directly to your employer's documentation. The NE-specific details change. The decision framework doesn't.

Component 2 — Governance cadence documents

IAM is not a project. It's an operational discipline with recurring activities. Each module that introduces a governance capability also defines the operational cadence — what happens daily (automated), weekly (reviewed), monthly (audited), and quarterly (certified).

Module 2 defines the lifecycle workflow cadence — daily execution monitoring, weekly failure review, monthly provisioning audit. Module 5 defines the access review cadence — which reviews run quarterly, which run semi-annually, which run annually. Module 9 defines the credential governance cadence — daily expiry alerting, monthly rotation status, quarterly attestation.

At capstone, you consolidate the per-module cadences into a single operational calendar. The calendar is the answer to "what does the IAM team do every day, every week, every month, every quarter?"

Component 3 — Risk register

Every module identifies governance gaps that can't be closed — licensing constraints that block a feature, organizational resistance that delays adoption, data quality problems that take months to remediate. Each gap becomes a risk register entry:

• Risk: What's the exposure?
• Likelihood and impact: How likely is it to materialize, and what's the consequence?
• Current control: What compensating control exists (if any)?
• Target control: What governance mechanism closes the gap?
• Status: Accepted, mitigated, or planned for remediation.

Your first risk register entries come from IAM1.7 — the governance state assessment produces findings that you can't immediately fix. The 80% missing employeeHireDate is a risk register entry: lifecycle workflows can't fire for most identities until the data quality problem is solved. The risk is documented, the compensating control is identified (manual provisioning as fallback), and the remediation target is set (HR system integration or CSV import).

Component 4 — Compliance evidence

Every governance capability produces evidence that maps to compliance framework controls. The mapping is built into the course — Module 13 consolidates it, but the evidence itself is generated as a byproduct of governance across Modules 2 through 12.

Access reviews produce evidence for ISO 27001 A.5.18 (access rights), SOC 2 CC6.1 (logical access), and NIST CSF PR.AC-1 (identities and credentials). Lifecycle workflows produce evidence for A.5.16 (identity management) and CC6.2 (prior to issuing access). Privileged access reviews produce evidence for A.8.2 (privileged access rights).

The compliance evidence component isn't a separate deliverable you create at the end. It's the accumulated audit trail of governance activities across the course. Module 13 organizes it by framework and teaches you to generate evidence reports on schedule.

Component 5 — Executive summary

The executive summary is the document Rachel Okafor presents to the board. It translates the technical governance program into business language — current state of identity governance, target state after program implementation, residual risk, investment required, and the metrics that prove the program works.

You write the executive summary in Module 14 after assembling the other four components. The summary references ADRs for decision justification, the governance cadence for operational commitment, the risk register for honest disclosure, and the compliance evidence for audit readiness. It's the one-page artifact that answers the CISO's question: "Do we have an IAM program, and can you prove it works?"

Module-to-package contribution map

Each module produces specific artifacts for the package. Here's what you'll build and where it goes:

Module 1 (Identity Ecosystem): First ADRs (IAM1-001 through IAM1-003). First risk register entries (attribute coverage gaps). Governance state assessment baseline.

Module 2 (Lifecycle Workflows): ADRs for provisioning source, workflow design, guest governance. Lifecycle cadence (daily/weekly/monthly). Risk entries for HR system gaps.

Module 3 (Group Architecture): ADRs for group strategy, naming convention, dynamic group design. Risk entries for ownerless groups.

Module 4 (Entitlement Management): ADRs for catalog structure, approval model, time-bound access. Cadence for package reviews and expiry management.

Module 5 (Access Reviews): ADRs for review scope, cadence, reviewer model. The review operational cadence. Compliance evidence for A.5.18/CC6.1/PR.AC-1.

Modules 6–8 (App Access, Privileged Access, Delegation): ADRs for consent policy, PIM model, delegation boundaries. Cadence entries for each governance domain.

Modules 9–11 (Non-Human Identity): ADRs for credential policy, permission model, agent governance. The non-human identity governance cadence. Risk entries for ungoverned machine identities.

Module 12 (Monitoring): KQL detection rules, dashboards, alert thresholds. The monitoring cadence. Governance health scoring methodology.

Module 13 (Compliance): Framework-to-control mapping. Automated evidence collection scripts. Maturity roadmap. The budget conversation artifact.

Module 14 (Capstone): Assembly of all components. Coherence review. Risk register finalization. ADR portfolio review. Executive summary. Three stakeholder defense simulations.

Set up your folder structure

Create a local folder structure for the program package. You'll add to it module by module:

IAM-Program-Package/
├── 01-ADRs/
│   └── README.md          ← ADR template and numbering convention
├── 02-Governance-Cadences/
│   └── README.md          ← Cadence format (daily/weekly/monthly/quarterly)
├── 03-Risk-Register/
│   └── README.md          ← Risk register format and scoring
├── 04-Compliance-Evidence/
│   ├── ISO-27001/
│   ├── SOC-2/
│   ├── NIST-CSF/
│   └── Cyber-Essentials/
├── 05-Executive-Summary/
│   └── README.md          ← Summary template (completed at capstone)
└── README.md              ← Package overview and module contribution tracker

Create this now. If you're working on Windows, PowerShell creates the structure:

$root = "IAM-Program-Package"
$folders = @(
  "$root/01-ADRs",
  "$root/02-Governance-Cadences",
  "$root/03-Risk-Register",
  "$root/04-Compliance-Evidence/ISO-27001",
  "$root/04-Compliance-Evidence/SOC-2",
  "$root/04-Compliance-Evidence/NIST-CSF",
  "$root/04-Compliance-Evidence/Cyber-Essentials",
  "$root/05-Executive-Summary"
)

foreach ($f in $folders) {
  New-Item -Path $f -ItemType Directory -Force | Out-Null
}

Write-Host "Created IAM Program Package folder structure"

The ADR template

Every ADR you write from IAM1.7 onward follows this format. Create this as 01-ADRs/README.md:

# Architecture Decision Records

## Naming Convention
IAM[Module]-[Sequence]: [Short Title]
Example: IAM1-001: Data Quality Remediation Strategy

## Template

### ADR IAM[X]-[NNN]: [Title]

**Context:** What problem are you solving? What constraints exist?
Include: licensing, hybrid environment, HR system gaps,
organizational politics, data quality.

**Decision:** What did you decide? Why this over alternatives?

**Alternatives considered:**
(a) [Alternative 1] — rejected because [reason]
(b) [Alternative 2] — rejected because [reason]

**Consequences:**
- Enables: [what this decision makes possible]
- Breaks: [what this decision prevents or complicates]
- Residual risk: [what risk remains after implementation]
- Compensating control: [what mitigates the residual risk]

**Communication (CISO summary — 30 seconds):**
"[One paragraph explaining the decision in business terms]"

The risk register template

Create this as 03-Risk-Register/README.md:

# Risk Register

## Naming Convention
[Category]-[Sequence]: [Short description]
Categories: DQ (data quality), GRP (groups), DEL (delegation),
LIC (licensing), NHI (non-human identity), PAG (privileged access)

## Template

### [ID]: [Title]

| Field | Value |
|---|---|
| Risk | [What is the exposure?] |
| Likelihood | [High/Medium/Low — how likely to materialize?] |
| Impact | [High/Medium/Low — what's the consequence?] |
| Current control | [What compensating control exists now?] |
| Target control | [What governance mechanism closes the gap?] |
| Remediation target | [Coverage % or date] |
| Status | [Open / In progress / Mitigated / Accepted] |

The governance cadence template

Create this as 02-Governance-Cadences/README.md:

# Governance Cadences

## Format
Each module adds a governance cadence — the operational rhythm
for the governance capability that module teaches.

## Template

### [Module Name] Governance Cadence

| Frequency | Activity | Owner | Tool |
|---|---|---|---|
| **Daily** | [Automated checks, workflow execution monitoring] | System | [Graph API / Portal] |
| **Weekly** | [Manual reviews, exception handling, blocked items] | [Role] | [Dashboard / Script] |
| **Monthly** | [Trend analysis, metric review, report generation] | [Role] | [Script / Portal] |
| **Quarterly** | [Certification, attestation, stakeholder review] | [Role] | [Access Reviews / PIM] |

Notes:
- Daily activities should be automated where possible
- Weekly activities are the operational heartbeat
- Monthly activities produce the metrics that quarterly reviews evaluate
- Quarterly activities produce compliance evidence

The compliance evidence structure

Create these placeholder files in 04-Compliance-Evidence/:

$root = "IAM-Program-Package/04-Compliance-Evidence"

# ISO 27001 Annex A controls relevant to IAM
Set-Content "$root/ISO-27001/README.md" @"
# ISO 27001 Compliance Evidence

## Relevant Annex A Controls
- A.5.15 Access control
- A.5.16 Identity management
- A.5.17 Authentication information
- A.5.18 Access rights
- A.8.2 Privileged access rights
- A.8.3 Information access restriction

Evidence generated from Module 5 (reviews) and Module 13 (compliance mapping).
"@

# SOC 2 Common Criteria
Set-Content "$root/SOC-2/README.md" @"
# SOC 2 Compliance Evidence

## Relevant Common Criteria
- CC6.1 Logical and physical access controls
- CC6.2 Prior to issuing system credentials
- CC6.3 Enrollment and registration of user identities

Evidence generated from Module 5 (reviews) and Module 13 (compliance mapping).
"@

Write-Host "Created compliance evidence README files"

Module 13 populates these folders with automated evidence collection scripts that map governance controls to framework requirements. The structure exists now so you understand the compliance target from the start — not as a Module 13 surprise.

The executive summary template

Create this as 05-Executive-Summary/README.md. Module 14 fills it in — the template gives you the structure now:

# IAM Program Executive Summary

## Governance State Before the Program
- Composite data quality score: [M1 baseline %]
- Group governance coverage: [M1 ownership %]
- Access review effectiveness: [M0 deny rate]
- Administrative delegation: [M1 AU count and scope state]
- Non-human identity governance: [M0 credential and permission state]

## What Was Built
- Lifecycle workflows deployed: [joiner/mover/leaver coverage %]
- Access review program: [scope, cadence, deny rate improvement]
- Entitlement management: [catalog count, active access packages]
- Delegation model: [AU count, scoped role assignments]
- Non-human identity governance: [credential policy, permission reviews]

## Current Governance Maturity
[Maturity self-assessment from IAM0.5, compared to M14 reassessment]

## Risk Register Status
[Open risks, mitigated risks, accepted risks with compensating controls]

## Budget Impact
- Governance licensing: [$X/year]
- Operational cost: [team hours per week]
- Consulting alternative: [$X one-time, no ongoing capability]

## Recommendation
[Continue / expand / specific next investment]

This template is the artifact Rachel presents to the board. Module 14 populates it with real data from your governance program. The template exists from Module 0 so every module's output is shaped by the executive summary it eventually feeds — ADRs inform the "What Was Built" section, risk register entries inform the "Risk Register Status" section, and governance cadences inform the "Operational Cost" line.

Verify your package structure

$root = "IAM-Program-Package"
$expected = @("01-ADRs", "02-Governance-Cadences", "03-Risk-Register",
  "04-Compliance-Evidence", "05-Executive-Summary")

Write-Host "=== PACKAGE STRUCTURE VERIFICATION ==="
foreach ($dir in $expected) {
  $exists = Test-Path "$root/$dir"
  Write-Host "  $dir: $(if ($exists) { 'OK' } else { 'MISSING' })"
}

This folder structure is your working directory for the course. Each module tells you which folder to add artifacts to. By Module 14, every folder has content and the package is the capstone deliverable.

Who uses the program package

Each component serves a different stakeholder. Understanding the audience determines how you write the content — technical depth for the implementation team, risk language for the CISO, compliance evidence for auditors, executive summaries for the board.

ADRs → the security architecture team. ADRs are the engineering decisions behind your governance program. When a new security architect joins the team and asks "why do we use manager-based access reviews instead of owner-based?", the ADR answers with the context, decision, alternatives considered, and trade-offs. ADRs prevent institutional knowledge loss — the decision survives the person who made it. The 30-second CISO summary on each ADR also makes them accessible to leadership for budget and direction conversations.

Governance cadences → the operations team. The cadence documents define what happens daily, weekly, monthly, and quarterly for each governance domain. When Phil transitions from ad-hoc administration to governed operations, the cadence tells him what to check on Monday (failed lifecycle workflows, pending access requests) and what to prepare for the quarterly review (privileged role attestation, service principal credential audit). Cadences convert governance from a project into an ongoing operational rhythm.

Risk register → the CISO and the GRC team. The risk register tracks governance gaps with quantified likelihood and impact, current compensating controls, and target remediation. Rachel uses it to prioritize investments — which gap has the highest risk exposure? Elena uses it to respond to audit findings — "we're aware of this risk, here's the remediation plan and timeline." The risk register is a living document that Module 14 finalizes but that you update continuously throughout the course.

Compliance evidence → auditors and assessors. The compliance evidence folder maps governance controls to framework requirements — ISO 27001 Annex A.5.18 (access control), SOC 2 CC6.1 (access management), NIST CSF PR.AC-1 (identity management). Module 13 builds the mapping and generates the evidence automatically. The compliance folder bridges the gap between "we do governance" and "here's proof that governance works, mapped to the requirements you're assessing."

Executive summary → the board and senior leadership. The executive summary (completed in Module 14) is a 2-page document that translates the governance program into business terms: what risk was identified, what was built, what risk remains, and what it costs. This is the document Rachel presents to the CFO when the Governance trial expires and the permanent licensing conversation happens.

At Northgate Engineering: Rachel Okafor maps the package components to her stakeholders. ADRs go to Marcus Webb (security architect) so he understands the governance design choices alongside his Conditional Access and Defender architecture. Governance cadences go to Phil Greaves — they convert his daily routine from reactive administration to proactive governance. The risk register stays with Elena Petrova — she maintains it and presents it at the monthly security leadership meeting. Compliance evidence goes to the external auditors at the next ISO 27001 assessment. The executive summary goes to the board quarterly, alongside the security metrics dashboard from Module 12.

Package lifecycle

The program package isn't static. It grows with every module and requires periodic maintenance:

During the course: Each module adds ADRs (2–4 per module), governance cadence entries (1 per module from M2 onward), risk register entries (varies by findings), and compliance evidence (from M5 onward). By Module 14, the package contains 30–50 ADRs, 12+ governance cadences, 20+ risk register entries, and framework-mapped evidence for 4 compliance standards.

After the course: The package becomes the governance program documentation. ADRs are updated when design decisions change. The risk register is reviewed monthly and entries are closed as remediations complete. Governance cadences are adjusted as operational patterns stabilize. Compliance evidence is refreshed before each assessment cycle. The executive summary is updated quarterly with current metrics.

Version control: If your team uses Git, version the package as a repository. ADR changes create commits. Risk register updates are tracked. The commit history provides an audit trail of governance decisions over time — useful for demonstrating continuous improvement to auditors.

Decision-point simulation

Scenario 1. You've completed Module 4 (Authentication) and produced ADRs for authentication method selection and strength policies. Module 5 (Conditional Access) introduces a design decision that contradicts your Module 4 ADR — you chose to disable SMS for all users, but the CA policy for guest access requires SMS as a fallback for partners without Authenticator. How do you handle the contradiction in the program package?

Update the Module 4 ADR with a revision. ADRs are living documents — contradictions between modules are expected as the design evolves. The revision adds a new consequence: "SMS remains available for guest sign-in scenarios where the external identity provider doesn't support phishing-resistant methods. This exception is scoped to the guest CA policy and does not apply to internal users." The ADR revision history shows the original decision, the Module 5 discovery, and the updated position. This is exactly the kind of cross-module coherence the capstone (M14) validates.

Scenario 2. Rachel Okafor (CISO) asks for a one-page summary of the IAM program's current state — you're at Module 3 of 14. She wants to present it to the board next week. The program package has 3 completed modules, 8 ADRs, and 2 risk register entries. Is that enough to present, and how do you frame an incomplete program?

Yes — present it as a phased program with progress to date. The board doesn't need 14 completed modules. They need: what the program covers (scope), what's been decided so far (3 modules, 8 ADRs), what's been identified as risk (2 register entries), and what's next (the remaining 11 modules with timeline). Frame the incomplete state as deliberate phasing, not slow progress. The IAM program package folder structure from this section shows the board exactly how comprehensive the final deliverable will be. The in-progress modules are placeholders with target dates, not gaps.