> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# HR security

> Workforce security — screening, onboarding, training, role transitions, and offboarding.

<Warning>
  **Status — April 2026**: Core practices are in place; formal HR security policy document is in draft. Target publication: **Q2 2026**. Audit finding: no HR security policy, no onboarding/offboarding records evidenced (18/100).
</Warning>

**Owner**: Head of People / HR (or designee) · **Security review**: Security Officer · **Policy version**: 0.9 (draft)

## Scope

This policy applies to every **member of the Denialbase workforce** — full-time employees, part-time employees, contractors, and consultants — at every stage of their time with Denialbase:

* Before employment (screening, agreements)
* During employment (training, access, role changes)
* Termination or role change (offboarding)

## Pre-employment

### Screening (Annex A.6.1)

<CardGroup cols={2}>
  <Card title="Background check" icon="shield-check">
    Required for all employees and contractors with production access. Scope includes identity verification, right-to-work, criminal record check (per local law), and employment history verification.
  </Card>

  <Card title="Reference check" icon="user-check">
    At least 2 professional references for employees.
  </Card>

  <Card title="Credential verification" icon="award">
    Professional licenses, certifications, and degrees verified where claimed or relevant to the role.
  </Card>

  <Card title="Sanctions screening" icon="ban">
    OFAC and equivalent sanctions-list screening; prohibited-party checks.
  </Card>
</CardGroup>

### Terms of employment (Annex A.6.2)

* **Employment agreement** — every employee signs a standard agreement before first-day access.
* **NDA / confidentiality clause** — built into the employment agreement for employees; standalone NDA for contractors/consultants.
* **IP assignment** — standard assignment of work-product IP to Denialbase.
* **Acceptance of policies** — new hires sign acknowledgement of the [AUP](/trust/acceptable-use-policy), [ISP](/trust/information-security-policy), and this policy on their first day.
* **BAA flowdown** — contractors whose role includes PHI access are covered by a BAA between Denialbase and the contracting entity (or the individual if independent).

## Onboarding

### Day 0 (pre-start)

* Offer accepted and employment agreement signed.
* Background + sanctions checks cleared (blocking).
* Workstation ordered, managed enrollment configured.
* GitHub, Google Workspace, 1Password, GCP accounts provisioned with least-privilege defaults.

### Day 1

* Workstation arrives, auto-enrolls in MDM on first boot.
* Employee sets up 2FA on all accounts.
* Reads and acknowledges: [ISP](/trust/information-security-policy), [AUP](/trust/acceptable-use-policy), [Privacy commitments](/trust/hipaa), this policy, and the security awareness primer.
* Attends a 90-minute new-hire security briefing.

### Week 1

* **Security awareness training** completed (see [Security awareness](/trust/security-awareness)).
* **HIPAA awareness training** completed (required for anyone with PHI exposure).
* **Phishing simulation baseline** taken.
* **Role-specific training** — developers get secure coding training; support staff get PHI-handling training.
* Manager confirms access requests are appropriate for the role.

### Day 30

* Buddy / mentor check-in focused on security practices.
* Confirm workstation policies are intact (FDE, EDR, patching).
* Confirm no extra access has been granted without ticketed justification.

### Day 90

* Manager reviews role alignment — any access that turns out to be unused is revoked.
* First security awareness comprehension check.

## During employment

### Access management

* **Least privilege** — every access grant is time-limited where practical and tied to a role or ticket.
* **Quarterly access reviews** — see [Access control policy](/trust/access-control-policy#access-review).
* **Privileged access** — production data access is just-in-time, requires CTO or Security Officer approval, time-limited, and audit-logged.
* **Shared accounts are prohibited** — no generic "admin" credentials; every action is attributable.

### Training (Annex A.6.3)

See [Security awareness](/trust/security-awareness) for the full program. Minimum:

* **Annual** HIPAA + security awareness refresher for everyone.
* **Role-specific** training for developers (secure SDLC), engineering managers (threat modeling), and anyone with privileged access.
* **Phishing simulations** monthly; follow-up training for click events.
* **Ad-hoc training** after any incident with a training-related root cause.

### Role changes (Annex A.6.5)

When a workforce member changes role:

<Steps>
  <Step title="Manager files a role change request">
    Specifies: new role, effective date, access changes needed (grants + revocations).
  </Step>

  <Step title="Security Officer reviews access delta">
    Confirms new access is appropriate; confirms old access is fully revoked (not additive-by-default).
  </Step>

  <Step title="IT implements access changes">
    Within 1 business day of the effective date.
  </Step>

  <Step title="Completion logged in HR record">
    For audit evidence.
  </Step>
</Steps>

### Discipline and sanctions (Annex A.6.4)

Violations of security policies may result in:

1. **Verbal warning** for minor first-time issues (e.g. forgot to lock laptop once).
2. **Written warning** for repeated minor issues or one-time moderate issues.
3. **Suspension** pending investigation for suspected serious policy breach.
4. **Termination** for willful or negligent breaches with material impact (e.g. sharing credentials, PHI leak).
5. **Legal action** for malicious breaches.

All disciplinary actions are documented in the HR record. The process is applied consistently regardless of seniority.

## Offboarding

Offboarding is the highest-risk HR transition — it's when "just in case" access tends to linger. We run a strict checklist:

<Steps>
  <Step title="Manager notifies HR + Security (T-0 or earlier)">
    As soon as termination is planned (amicable or not), HR and Security are notified. For involuntary termination, the timing is typically same-day.
  </Step>

  <Step title="Revoke access (T-0)">
    On the termination effective date:

    * Terminate all active sessions (GCP, GitHub, Google Workspace, 1Password, Denialbase admin).
    * Disable accounts (not delete — we keep audit trail).
    * Remove from Slack, email distribution lists, incident pager rotations.
    * Revoke SSO grants; remove from IAM bindings.
    * Collect physical access tokens (YubiKeys, swag with embedded auth, etc.).
  </Step>

  <Step title="Collect assets (T-0 to T+7)">
    Managed workstation returned via shipping label; MDM wipes on receipt. Any other company property (swag, keys, hardware tokens) returned.
  </Step>

  <Step title="Confirm removal completeness (T+1 business day)">
    Security Officer verifies via IAM audit log that no access remains. Logged confirmation stored in HR record.
  </Step>

  <Step title="Data portability (T+0 to T+30)">
    Departing member can download personal data per applicable law. Work product stays with Denialbase.
  </Step>

  <Step title="Retain records (permanent)">
    HR records, including access history, retained per applicable law (typically 6+ years for US employees).
  </Step>
</Steps>

## Records retained

| Record                               | Retention                                     |
| ------------------------------------ | --------------------------------------------- |
| Employment agreement + amendments    | Employment + 6 years                          |
| Background check records             | Employment + 6 years (or per vendor contract) |
| Policy acknowledgements              | Employment + 6 years                          |
| Training completion                  | Employment + 6 years                          |
| Access grants and revocations        | 7 years (same as audit logs)                  |
| Role change records                  | Employment + 6 years                          |
| Disciplinary records                 | Employment + 6 years                          |
| Offboarding checklist + confirmation | 7 years                                       |

## Current gaps — honest status

<AccordionGroup>
  <Accordion title="Formal HR policy document">
    Practices above are in place but not consolidated into a single signed-off policy document. Target: published Q2 2026 and referenced in employment agreements going forward.
  </Accordion>

  <Accordion title="Evidenced onboarding/offboarding records">
    Today's records live in disparate systems (email, Slack, tickets). Consolidation into a per-employee record with the checklists above attached is in progress.
  </Accordion>

  <Accordion title="Formal security awareness curriculum">
    New-hire briefing and annual refresher exist; structured curriculum with documented learning objectives is being built.

    *See [Security awareness](/trust/security-awareness).*
  </Accordion>
</AccordionGroup>