SS-SOC2-001A Checklist
SKYE Standard control checklist: mandatory domains + applicable modules, with status tracking and export.
Fill system details first. Then mark every control as ✅ Done, 🟡 Partial, ❌ Not Implemented, or N/A. Every ❌ must be remediated with a due date or covered by an approved SS-SOC2-001D exception.
Tip: Use the filter box to find controls fast. Ex: type MFA or access review.
Loading…
Section 0 — System Identification (Required)
SS-SOC2-001A — Checklist
Interactive checklist. Status saves locally to this device and exports as JSON.
1 — Identity & Access Control (SS-IAM) (Mandatory)
1.1 — MFA enforced for all privileged accounts (admin, cloud consoles, DB, CI/CD).
1.2 — No shared privileged accounts; named accounts only.
1.3 — RBAC defined for application and infrastructure.
1.4 — Least privilege implemented (no broad owner roles without justification).
1.5 — Joiner/Mover/Leaver process documented and used.
1.6 — Offboarding SLA defined and met (same-day target for privileged access).
1.7 — Access reviews completed on required cadence (quarterly minimum; monthly high-risk).
1.8 — Break-glass access exists, is logged, and reviewed.
1.9 — API keys/tokens are scoped and rotated; no uncontrolled long-lived secrets.
1.10 — Service accounts are limited, monitored, and reviewed.
2 — Change Management (SS-CHG) (Mandatory)
2.1 — All production changes tracked (PR/ticket required).
2.2 — Approvals required for production changes (defined approver role).
2.3 — Separation of duties for sensitive changes (when feasible).
2.4 — CI checks enforced (lint/test/build; dependency scan where applicable).
2.5 — Deployment logs retained and searchable.
2.6 — Rollback plan exists for production releases.
2.7 — Emergency changes process exists and is audited.
2.8 — Infrastructure changes are version-controlled (IaC or traceable equivalent).
3 — Logging, Monitoring, Alerting (SS-OBS) (Mandatory)
3.1 — Centralized logging enabled for auth, admin actions, and application events.
3.2 — Audit logs enabled for cloud provider / identity provider / database.
3.3 — Alerts configured for auth anomalies (brute force, impossible travel, suspicious admin actions).
3.4 — Alerts configured for availability and error rate thresholds.
3.5 — Log retention configured per risk (minimum policy specified and enforced).
3.6 — Time synchronization enabled (NTP) to ensure reliable timestamps.
3.7 — Access to logs restricted and reviewed.
3.8 — Evidence of alert testing exists (at least quarterly).
4 — Vulnerability & Patch Management (SS-VULN) (Mandatory)
4.1 — Dependency scanning enabled (SCA).
4.2 — Vulnerability triage process defined (severity, owner, SLA).
4.3 — Patch SLAs defined and met (example: Critical 7d, High 14d, Medium 30d, Low 90d).
4.4 — OS/container/base image patching documented and executed on cadence.
4.5 — Periodic vulnerability scans performed (cadence defined).
4.6 — Remediation tickets tracked to closure (no silent backlog).
4.7 — Secrets scanning enabled for repositories and build pipelines.
5 — Incident Response (SS-IR) (Mandatory)
5.1 — Incident severity levels defined (SEV scale).
5.2 — On-call/escalation path defined and current.
5.3 — Incident response runbook exists and is accessible.
5.4 — Tabletop exercise performed at least annually (quarterly for high-risk).
5.5 — Post-incident review process exists (root cause + corrective actions).
5.6 — Incident logs/tickets retained and searchable.
5.7 — Client notification criteria documented (if applicable).
6 — Data Protection & Secrets (SS-DATA) (Mandatory)
6.1 — TLS enforced for all external traffic; internal encryption where feasible.
6.2 — Encryption-at-rest enabled for databases and object storage (where supported).
6.3 — Secrets stored in approved secret manager / env vars; never committed to code.
6.4 — Secret rotation policy defined and followed.
6.5 — Data classification policy applied to system datasets.
6.6 — Data retention + deletion policy implemented.
6.7 — Backups are encrypted and access-controlled.
6.8 — Data access is logged for sensitive datasets.
7 — Vendor & Third-Party Risk (SS-VEND) (Mandatory)
7.1 — Vendor inventory maintained for critical vendors (cloud, auth, DB, payments, email).
7.2 — Vendor access is least-privilege and reviewed.
7.3 — Security attestations collected when available (SOC reports for critical vendors).
7.4 — Subprocessor list maintained (if handling customer data).
7.5 — Contractual security requirements tracked (SLAs, breach notice terms).
8 — Availability & Disaster Recovery (SS-AVL) (Required if uptime promised / critical)
8.1 — Uptime objective defined (SLO/SLA).
8.2 — Backups scheduled and monitored.
8.3 — Restore test performed at least annually (quarterly for critical).
8.4 — DR plan documented with RTO/RPO targets.
8.5 — Redundancy implemented where required.
8.6 — Capacity monitoring in place.
9 — Confidentiality (SS-CONF) (Required if sensitive business data)
9.1 — Data classification applied and enforced for sensitive datasets.
9.2 — Sensitive data access restricted and reviewed more frequently.
9.3 — DLP controls applied where appropriate (email/storage).
9.4 — Field-level protections used where needed (masking/tokenization).
10 — Processing Integrity (SS-PI) (Required if correctness is contractually important)
10.1 — Input validation + error handling standards defined and used.
10.2 — Reconciliation or audit trails exist for critical transactions.
10.3 — Job/queue retries are safe and monitored.
10.4 — Data integrity checks exist for critical flows.
11 — Privacy (SS-PRIV) (Required if personal data)
11.1 — Privacy notice and data use purpose defined.
11.2 — Data subject request (DSR) process defined (access/delete/export).
11.3 — Data minimization enforced (collect only what’s needed).
11.4 — Consent handling documented where required.
11.5 — Retention policy aligns with privacy requirements.
12 — AI Add-On Controls (SS-AI) (Required if AI/LLM is used)
12.1 — Model access governed (scoped keys, caps, audit logs).
12.2 — Sensitive data handling rules defined (no secrets in prompts).
12.3 — Output logging for high-impact workflows (redaction where required).
12.4 — Human review for high-risk decisions (when applicable).
12.5 — Prompt/version changes follow change control.
12.6 — Abuse monitoring and rate limiting enabled.
Completion Gate (SKYE Enforcement)
- To reach Level 2: Mandatory sections 1–7 must be ✅ Done or 🟡 Partial with remediation due dates; no open ❌ without an approved exception.
- To reach Level 3: Mandatory sections ✅ Done; all applicable modules ✅ Done; evidence complete for the audit period; quarterly reviews current.
