Procedure 04 ADMINISTRATIVE
Onboarding / Hiring Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 04 · PCI DSS Req 12.6, 12.7 · 0 of 6 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 04 — Onboarding / Hiring PolicyThe rule this procedure implements
How Revique implements this today
Onboarding is a people process; its AWS-visible outcome is the access an individual ends up with. New members are given a named IAM user or a federated role in the accounts their role requires — there are 10 IAM users in dev, 10 in UAT and 7 in production, and the naming convention is per-person (no shared human accounts among them, though several machine/integration identities exist). Access is provisioned only in the environments the role needs, which is why the production account carries the fewest identities.
The rule against the current state
Each row takes a statement from Policy 04 and states what is actually configured. Meets = implemented as written. Partial = implemented, but not everywhere or not to the full standard. Gap = not implemented. N/A = not verifiable from infrastructure configuration.
| The rule | Current state | Verdict |
|---|
| Onboarding completed before access to production is granted | Sequencing is procedural; AWS records only the end state (user creation date, in the credential report). | Partial |
| Background screening before CHD/PHI access | See Procedure 21. HR record, not visible in AWS. | Partial |
| Access provisioned on least privilege | Production holds 7 identities versus 10 in each lower environment, consistent with restricting production access. Per-identity permission scoping is assessed in Procedure 07. | Partial |
| Policy acknowledgement before access | Administrative record. | Partial |
| Initial security awareness training during onboarding | See Procedure 06. Administrative record. | Partial |
| Onboarding records documented and retained | Administrative record. | Partial |
🔍 Auditor verification — where to log in and what you will see
Who has access, and since whenConsole → IAM → Users in each account, or IAM → Credential report — the user_creation_time column dates each identity.
Access is per-personIAM → Users — human identities are individually named; machine identities (build, SMTP, monitoring) are separately named and have no console password.
The onboarding record itselfAsk HR for the onboarding checklist, screening result, signed policy acknowledgement and training completion for a sampled hire, and match the date against that user's IAM creation date.
Team process
The hiring manager initiates the onboarding checklist and screening. The Security Officer confirms that screening, policy acknowledgement and initial training are complete. Only then does DevOps create the IAM identity, granting the minimum set of permissions the role requires and adding production access only if the role genuinely needs it.
⚠️ Where reality does not meet the policy
- The link between an onboarding record and an IAM user creation is not evidenced anywhere — an auditor sampling a user cannot confirm from AWS that screening and acknowledgement preceded access.
- Several long-lived machine identities predate the current process (access keys last rotated 2019–2022, see Procedure 07/08) and have no corresponding onboarding record.
Evidence location. Onboarding checklists, screening results, signed acknowledgements and training completions are HR records held outside AWS.
📘Back to the PolicyPolicy 04 — Onboarding / Hiring Policy (PCI DSS Req 12.6, 12.7)←