Employee Data Security Checklist

Assign the KnowBe4 or Vanta-issued module covering phishing, social engineering, and customer-data handling. SOC 2 CC1.4 requires annual training with evidence; quarterly cadence keeps the evidence fresh and surfaces drop-offs early.

Send a credential-harvest simulation through KnowBe4 or GoPhish. Track click-through and credential-submit rates separately — clicks are noise, submits are the real signal. Engineers with prod access who submit credentials get a follow-up 1:1.

Pull the AWS IAM Access Analyzer report and the GitHub org admin list. Anyone with AdministratorAccess, iam:*, or write access to the prod cluster needs a named business reason. Stale roles from contractors or rotated team members are the common finding.

Confirm Okta or Google Workspace SSO is enforced on GitHub, AWS, Datadog, PagerDuty, and the secrets manager. Check for any local accounts that bypass SSO — break-glass roles are fine if documented; service users that drifted out of SSO are the gotcha. WebAuthn / hardware key required for admin tiers.

Cross-check HRIS termination list against GitHub, AWS, k8s RBAC, Datadog, PagerDuty, and any vendor SaaS not behind SCIM. SCIM covers the easy 80%; the remaining vendors (1Password vault shares, Sentry, Linear) are where the offboarding gap usually shows up.

Run gitleaks or trufflehog across the org and review GitHub secret-scanning alerts. Rotating an exposed key is necessary but not sufficient — the secret stays in git history until you rewrite with git-filter-repo or BFG. Confirm pre-commit hooks are installed on engineer workstations.

Rotate at the issuer (AWS IAM, Stripe, third-party APIs), update the secret in AWS Secrets Manager or Vault, redeploy consumers, then rewrite the git history. Notify any vendor whose key leaked publicly — most have a credential-leak intake.

Verify RDS, S3, EBS, ElastiCache, and any DynamoDB tables are encrypted with customer-managed KMS keys (not just AWS-managed). For HIPAA workloads the BAA requires CMK; for SOC 2 either is acceptable but CMK gives you the key-rotation audit trail.

Pull the Kandji, Jamf, or Intune device list and reconcile against the active engineer roster. Confirm FileVault / BitLocker enabled, OS version current, and EDR agent (CrowdStrike, SentinelOne) reporting in. BYOD or unenrolled personal Macs accessing prod are the typical SOC 2 finding.

Pull Tailscale, Twingate, or AWS SSM Session Manager logs for the quarter. Production SSH should be break-glass; if you see routine console sessions, that's an auditor flag. Cross-reference console-session timestamps with incident tickets to confirm justification.

Confirm RDS automated snapshots, S3 versioning + cross-region replication, and any application-level backup jobs ran clean for the last 30 days. A green success metric for 18 months running is not the same as a usable backup — that's what the next step is for.

Pick a recent RDS snapshot, restore into the staging account, run schema validation and a row-count check against the production replica. The restore script depends on credentials, KMS key grants, and VPC config that drift over time — quarterly drill is the only proof the runbook still works.

Pull CloudTrail for IAM policy changes, root-account use, and disabled-MFA events. Check Datadog Cloud SIEM or GuardDuty for unresolved findings. The audit-log retention window itself is a SOC 2 control — confirm it's at least 365 days.

Upload the access review export, training completion report, restore-drill log, and CVE triage summary into Vanta or Drata under the appropriate trust-services-criteria control. Tag each artifact with the quarter and the named reviewer.