APO07: Managed Human Resources

The apo07: managed human resources requirement is a governance expectation: people are part of the control environment, and you need repeatable, evidenced processes that ensure the right individuals are hired, trained, assigned, and removed from roles that can materially affect technology risk. If your IT controls depend on a small set of admins, developers, cloud engineers, SOC analysts, or third-party operators, APO07 is where auditors and customers test whether your organization can sustain those controls through staffing changes.

This requirement shows up in practice during access reviews, privileged access management failures, rushed onboarding, and messy offboarding. The patterns are predictable: a terminated contractor still has access; a new engineer pushes to production without secure coding training; nobody can explain who owns a key control; or “training” is a PDF with no completion record. APO07 is the corrective: define the roles that matter, define what “qualified” means for each, run HR workflows that enforce those requirements, and keep evidence that the system works.

COBIT is a framework, not a law, but it is widely used as a reference model for governance and management of enterprise IT ¹. Your job is to translate the objective into control statements, owners, triggers, and artifacts you can run and defend ².

Regulatory text

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

Operator interpretation: APO07 expects you to manage human resources in a way that maintains effective governance and operation of enterprise IT controls. In practical terms, you must:

• Define IT-relevant roles and responsibilities (including security and risk roles), and assign accountable owners.
• Ensure people in those roles are competent, including training and role-specific requirements.
• Manage staffing lifecycle events (joiner/mover/leaver) so access, responsibilities, and knowledge transfer are controlled.
• Retain evidence that these practices are performed consistently and are monitored for gaps ³.

Plain-English requirement statement (what APO07 is asking for)

If a person can build, change, approve, operate, or access key systems, you need an HR-backed control system that:

1. puts the right person in the role,
2. gives them the right access at the right time,
3. trains them on what they must do and must not do, and
4. removes access and responsibilities quickly and completely when their status changes.

Think of APO07 as “people lifecycle controls for IT risk.”

Who it applies to

Entity scope: Enterprises and IT organizations using COBIT as a governance framework, including regulated companies that map COBIT to their control environment ⁴.

Operational scope (where it bites):

• Teams running production systems (IT ops, SRE, platform engineering)
• Security operations, vulnerability management, and incident response
• Development teams with commit and deployment rights
• IAM/PAM administrators and directory service owners
• GRC/control owners who execute and evidence controls
• Third parties with administrative access or operational responsibility (managed service providers, contractors, consultants)

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

Use this as an implementation runbook for the apo07: managed human resources requirement.

1) Build an “APO07 control card” (one page)

Create a control card that makes APO07 auditable and runnable:

• Objective: Maintain competent, authorized staffing for IT control execution.
• Owner: HR process owner plus IT control owner (name both).
• In-scope roles: List roles with elevated risk (examples below).
• Trigger events: Hire, contractor onboarding, internal transfer, role change, privileged access request, termination, contract end, extended leave.
• Cadence: Define how often you review role definitions, training status, and exceptions.
• Exceptions: Who can approve exceptions (e.g., emergency access), how long they last, and required after-the-fact review. This aligns with turning framework expectations into executable controls ².

In-scope role examples (tailor to your environment):

• Cloud/platform admin, IAM admin, database admin
• CI/CD admin, release manager, production deploy approver
• SOC analyst, incident commander, forensics lead
• Security engineer managing detection rules
• Third-party operations roles with admin access

2) Define role-based requirements (competency + policy + control duties)

For each in-scope role, document:

• Responsibilities: What systems they operate and what controls they execute.
• Minimum competencies: Required training/certs/experience (keep it measurable).
• Required training modules: Secure coding, change management, data handling, incident reporting, acceptable use, phishing awareness (pick what is relevant).
• Segregation of duties (SoD): Activities they cannot combine (e.g., “approve own production change”).
• Access baseline: Which groups/permissions are allowed, and which are prohibited.

Deliverable: a role requirements matrix that HR and IT both recognize as authoritative.

3) Operationalize Joiner/Mover/Leaver (JML) workflows tied to access controls

Your biggest APO07 risk sits in JML. Implement three workflows with clear handoffs:

Joiner

• Manager request with role assignment mapped to the role requirements matrix.
• HR verification (employment status, start date, background checks if applicable to your internal policy).
• IAM provisioning based on approved role access baseline.
• Training assignment at onboarding; require completion before privileged access is granted where feasible.
• “Control owner assignment” if the role owns a control activity (document it in your GRC system).

Mover

• Manager initiates role change; old access removed, new access granted.
• SoD check (even a simple checklist) before approval.
• Update on-call rosters, runbooks ownership, and incident communications lists.

Leaver

• Immediate disablement process for accounts, tokens, VPN, SSO, PAM, and shared secrets.
• Reassignment of control ownership and operational duties.
• Retrieve assets and revoke third-party access pathways.
• Document completion and any exceptions (e.g., legal hold requiring mailbox preservation).

4) Prove training completion and effectiveness (not just assignment)

Auditors rarely accept “training exists.” They ask: who completed it, when, and how do you know it matters?

Minimum approach:

• Maintain a training register mapped to roles.
• Track completion records from LMS or equivalent system.
• Require attestations for key policies (acceptable use, code of conduct, data handling).
• For high-risk roles, add a practical validation step: peer review requirement, admin runbook walkthrough, incident tabletop participation, or supervised change window.

5) Manage third-party personnel as first-class APO07 scope

If a third party performs admin work or runs your systems:

• Contractually require role qualification and training alignment where appropriate.
• Enforce access via your IAM/PAM, not theirs.
• Include them in JML controls: named users, start/end dates, approval, and removal.
• Keep an inventory of third-party privileged access and who approved it.

6) Run control health checks and remediation tracking

APO07 fails quietly over time. Add a recurring operational check:

• Sample recent JML tickets and verify access changes match approvals.
• Identify overdue training for privileged roles.
• Confirm terminated users are absent from IAM, SSO, PAM, and key SaaS admin consoles.
• Track findings to closure with owners and due dates ².

Daydream fit: use Daydream to standardize the APO07 control card, define the minimum evidence bundle, and track recurring health checks and remediation to validated closure ².

Required evidence and artifacts to retain

Keep evidence tight and reproducible. A good APO07 evidence bundle usually includes:

Evidence item	What it proves	Where it lives
Role requirements matrix	Defined competencies, training, access baselines	GRC repository / controlled wiki
Org chart or RACI for IT control ownership	Clear responsibility and accountability	GRC tool / governance docs
JML tickets (join/move/leave) with approvals	Controlled lifecycle and access governance	ITSM/IAM system
Access provisioning/deprovisioning logs	Access changes actually occurred	IAM/SSO/PAM audit logs
Training completion exports	People met training requirements	LMS records
Policy attestations	Users acknowledged key rules	HR/LMS/attestation tool
Exception records	Exceptions were approved and time-bounded	GRC/ITSM
Control health check reports + remediation	Ongoing monitoring and fixes	GRC/issue tracker

Retention period: follow your internal retention schedule; auditors mainly care that you can produce prior-cycle evidence and show consistency.

Common exam/audit questions and hangups

Expect these, and prepare scripted answers plus evidence pointers:

1. “Show me your in-scope roles and who is in them.”
   Hangup: role definitions exist, but no authoritative roster.

2. “Walk me through a recent termination. When was access removed?”
   Hangup: HR termination date doesn’t match IT disablement timestamp.

3. “How do you ensure privileged users are trained before they get admin access?”
   Hangup: training assigned after access is granted, with no compensating control.

4. “How do you prevent a developer from approving their own production change?”
   Hangup: SoD is written but not enforced in tooling.

5. “How do you govern third-party administrators?”
   Hangup: shared accounts, no named-user accountability, no end dates.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating APO07 as an HR-only policy.
  Fix: co-own the control with IT/security, and tie it to access, change management, and incident roles.

• Mistake: “training” with no records.
  Fix: require LMS exports or completion screenshots, and store them in a defined evidence location.

• Mistake: incomplete offboarding (SaaS admins, API tokens, secrets).
  Fix: maintain a deprovisioning checklist covering SSO, PAM, cloud consoles, code repos, CI/CD, and secrets managers.

• Mistake: role sprawl and exceptions becoming the norm.
  Fix: keep a short list of privileged roles, define baselines, and review exceptions with expiration.

• Mistake: no linkage between control ownership and people changes.
  Fix: add “control owner update” as a required step in mover/leaver workflows.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for APO07. Treat APO07 as a “control environment” requirement that becomes high exposure when it drives real outcomes: unauthorized access, weak segregation of duties, control failures after reorgs, and poor third-party access governance. Customers and auditors commonly test these areas because they map directly to preventable operational incidents ².

Practical 30/60/90-day execution plan

Use phased execution without assuming fixed effort.

First 30 days (stabilize)

• Identify in-scope privileged and control-owner roles; publish a first-pass role list.
• Create the APO07 control card with owner, triggers, cadence, and exception rules.
• Document current JML process flows and gaps; prioritize leaver/offboarding.
• Define the minimum APO07 evidence bundle and the system of record for each artifact ².

Days 31–60 (implement and connect systems)

• Build the role requirements matrix: competencies, training, access baselines, SoD constraints.
• Update JML workflows in ITSM/IAM: required approvals, required checklists, and closure criteria.
• Stand up training tracking: LMS mapping to roles, completion reporting, and overdue escalation.
• Add third-party personnel controls: named accounts, start/end dates, approval workflow.

Days 61–90 (prove operation and harden)

• Run the first control health check: sample JML events, verify access logs, validate training completion for privileged roles.
• Remediate gaps with tracked issues to closure (owners, due dates, evidence of fix) ².
• Run an access-and-training attestation for role owners: confirm rosters, SoD adherence, and exceptions with expiration.
• Package a “ready for audit” APO07 evidence folder with a simple index and retrieval instructions.

Frequently Asked Questions

Does APO07 apply to non-IT staff?

APO07 is most testable for roles that can affect enterprise IT governance, security, and control execution. Start with privileged access holders, production operators, and control owners, then expand scope if your risk assessment supports it ⁵.

How do I scope “in-scope roles” without boiling the ocean?

Scope by impact: who can change production, access sensitive data, administer identity systems, or override controls. Keep the initial list short and defensible, then add roles after you can evidence the process is working ².

What evidence do auditors usually reject for APO07?

Auditors commonly reject statements like “training is required” without completion records, or offboarding processes without timestamps showing access removal. They also flag shared admin accounts because you cannot tie actions to an individual.

How do we handle emergency access without failing APO07?

Document an exception path with approvals, tight time bounds, and after-the-fact review. Keep the exception ticket, access logs, and the post-incident review together so you can show governance, not improvisation ².

Do contractors and managed service providers fall under APO07?

Yes, if they operate your systems or have access that could affect IT controls. Treat third-party personnel as named users with the same JML controls, training expectations where appropriate, and verified offboarding.

What is the fastest way to operationalize APO07 in a GRC program?

Create a control card, define the evidence bundle, and schedule a recurring health check with remediation tracking. Daydream can standardize those artifacts and keep ownership, cadence, and evidence retrieval consistent across teams ².

Footnotes

1. ISACA COBIT overview

2. ISACA COBIT usage guidance

3. ISACA COBIT usage guidance; OSA COBIT 2019 objective mapping

4. ISACA COBIT overview; OSA COBIT 2019 objective mapping

5. OSA COBIT 2019 objective mapping