{ "questionnaire": "SIG Lite", "version": "2026", "vendor": "CMDash, Inc.", "vendorUrl": "https://cmdash.com", "contact": "security@cmdash.com", "dateCompleted": "2026-10-09", "completedBy": "security@cmdash.com", "scope": "CMDash multi-tenant SaaS platform, hosted on AWS us-east-1. Excludes on-prem self-hosted deployments which inherit the customer's own controls.", "notes": "Every 'Yes' answer points to a shipped artifact (doc, code path, or Trust Center page). Every 'No' states the planned remediation honestly with a target sprint or quarter. 'Partial' is used where a control exists but enforcement or evidence collection is incomplete.", "sections": [ { "id": "A", "title": "Risk Management & Risk Assessment", "questions": [ { "id": "A.1", "question": "Do you have a documented information security program?", "answer": "Yes", "evidence": "/docs/compliance/soc2-type-ii-controls-mapping.md (CC1-CC9 + A1 trust criteria mapping). Public summary at /trust/security." }, { "id": "A.2", "question": "Is the information security program approved by executive management and reviewed at least annually?", "answer": "Partial", "evidence": "The security program is owned by CMDash's single maintainer, and the SOC 2 control mapping is reviewed as part of regular engineering work. There is no separate executive or board approval step.", "notes": "Formal annual board attestation would sit on a future SOC 2 Type II audit critical-path; no SOC 2 audit period has started and no start date is set (see /trust/soc2)." }, { "id": "A.3", "question": "Do you maintain a formal risk register identifying threats, likelihoods and impacts?", "answer": "Yes", "evidence": "CMDash operates its own product against itself — internal-tenant risks tracked in apps/api/src/risks/* and surfaced in /risks. SOC 2 mapping references it under CC3.1." }, { "id": "A.4", "question": "Are risks reassessed when significant changes occur (architecture, vendors, regulation)?", "answer": "Yes", "evidence": "/architecture/09-known-debt.md captures every change-driven caveat; risk re-assessment is triggered by any improvement-catalog item touching the threat model." }, { "id": "A.5", "question": "Do you maintain a formal risk-treatment plan with owners and target dates?", "answer": "Yes", "evidence": "/docs/improvement-catalog.md groups remediations by sprint and owner; debt ledger tracks dated caveats." }, { "id": "A.6", "question": "Do you have a documented and tested business impact analysis (BIA)?", "answer": "Partial", "evidence": "RTO/RPO and tier-1 dependencies are documented in /docs/sre/slos.md and /docs/cloud-deployment-runbook.md.", "notes": "Standalone BIA document does not yet exist. No SOC 2 audit period has started and no start date is set (see /trust/soc2)." }, { "id": "A.7", "question": "Do you carry cyber-liability insurance?", "answer": "No", "notes": "CMDash does not currently carry a cyber-liability insurance policy." }, { "id": "A.8", "question": "Do you perform formal vendor risk assessments before onboarding subprocessors?", "answer": "Yes", "evidence": "Subprocessor list maintained at /trust/subprocessors with purpose, region, and legal basis. Each new vendor reviewed against this template before procurement signs the order form." }, { "id": "A.9", "question": "Are residual risks formally accepted by the risk owner?", "answer": "Yes", "evidence": "Debt-ledger entries (architecture/09-known-debt.md) require a named owner and a target sprint or 'accepted residual' tag." }, { "id": "A.10", "question": "Do you have ISO 27001 certification?", "answer": "No", "notes": "ISO 27001 is on the roadmap post-SOC 2 Type II attestation. Not currently certified; no scheduled audit." } ] }, { "id": "B", "title": "Security Policies & Procedures", "questions": [ { "id": "B.1", "question": "Do you have a written information security policy reviewed at least annually?", "answer": "Yes", "evidence": "Policies live in /docs/security/ (authentication, http-headers, supply-chain) and /docs/runbooks/ and are version-controlled. CMDash has a single maintainer, so there is no separate policy-approval step." }, { "id": "B.2", "question": "Is there a formal acceptable-use policy for all personnel?", "answer": "Partial", "evidence": "Acceptable-use expectations are published at /acceptable-use and documented in the repository. CMDash has a single maintainer, so there is no personnel acknowledgement process." }, { "id": "B.3", "question": "Are policies communicated to all employees and contractors?", "answer": "Partial", "evidence": "Policies are version-controlled and visible to everyone with repository access. CMDash has a single maintainer, so there is no onboarding acknowledgement process." }, { "id": "B.4", "question": "Do you have a documented data classification policy?", "answer": "Partial", "evidence": "Tag taxonomy at /docs/developers/tags.md classifies internal data; customer-data classification follows the contractual DPA terms.", "notes": "Standalone customer-facing data-classification matrix planned for Q3 2026." }, { "id": "B.5", "question": "Do you have a documented data retention and disposal policy?", "answer": "Partial", "evidence": "Retention defaults defined in /apps/web/src/app/(dashboard)/data-retention/. Tenant deletion cascades via FK constraints.", "notes": "Crypto-erasure on tenant deletion (envelope-encryption tear-down) is a known gap (improvement-catalog III.2.3)." }, { "id": "B.6", "question": "Are exceptions to security policies formally documented and approved?", "answer": "Yes", "evidence": "Every exception lives in architecture/09-known-debt.md as a dated caveat with a named owner." }, { "id": "B.7", "question": "Do you have a documented change-management policy?", "answer": "Partial", "evidence": "Documented in the SOC 2 mapping (CC8): Every change is committed with a conventional-commit message and runs through the automated gates (lint, typecheck, tests, secret scan); main blocks force-pushes. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2). Schema migrations live under apps/api/prisma/migrations/." }, { "id": "B.8", "question": "Do you have a documented vulnerability management policy with severity-based remediation SLAs?", "answer": "Yes", "evidence": "/trust/pentest publishes severity-based remediation SLAs (Critical 7d or a mitigating control within 48h, High 30d, Medium 60d, Low/Informational 90d or a written rationale). Dependency CVEs auto-PR'd via /docs/developers/dependency-updates.md." }, { "id": "B.9", "question": "Do you have a documented incident-response policy with defined roles?", "answer": "Yes", "evidence": "/docs/runbooks/secret-leak-response.md is the canonical IR runbook; on-call rotation owns initial triage." }, { "id": "B.10", "question": "Are policies version-controlled with an audit trail?", "answer": "Yes", "evidence": "All policies live in this git repo; full author + date history available via git log on /docs/security/, /docs/compliance/, /docs/runbooks/." } ] }, { "id": "C", "title": "Organizational Security", "questions": [ { "id": "C.1", "question": "Is there a designated CISO or security lead with executive accountability?", "answer": "Partial", "evidence": "Security accountability sits with CMDash's single maintainer (see /trust/soc2).", "notes": "A formal org chart and information-security responsibility statement are open management items." }, { "id": "C.2", "question": "Are security responsibilities segregated from operational duties where appropriate?", "answer": "No", "evidence": "Every change is committed with a conventional-commit message and runs through the automated gates (lint, typecheck, tests, secret scan); main blocks force-pushes. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2)." }, { "id": "C.3", "question": "Are personnel screened (background check) before being granted access to customer data?", "answer": "No", "notes": "CMDash currently has a single maintainer and operates no formal background-screening programme." }, { "id": "C.4", "question": "Do contractors and temporary workers sign confidentiality agreements?", "answer": "Yes", "notes": "Contractor MSA includes NDA + confidentiality clauses; legal@cmdash.com owns the template." }, { "id": "C.5", "question": "Is there a formal security-awareness training program for all personnel?", "answer": "Yes", "evidence": "Onboarding requires reading /docs/security/* and /docs/runbooks/secret-leak-response.md. Annual refresh is a calendar event for the engineering org." }, { "id": "C.6", "question": "Do you have a documented disciplinary process for security-policy violations?", "answer": "Yes", "notes": "Security violations are handled under the acceptable-use expectations documented in the repository." }, { "id": "C.7", "question": "Is access removed within one business day of termination?", "answer": "Yes", "evidence": "SCIM v2 deprovisioning at apps/api/src/saml/scim.controller.ts; refresh-token rotation expires stale sessions; LDAP-sync prunes within the next sync cycle." }, { "id": "C.8", "question": "Do you maintain a documented org chart with reporting lines?", "answer": "Partial", "notes": "A formal org chart is an open management item (see /trust/soc2)." }, { "id": "C.9", "question": "Is there a process for periodic access reviews (at least quarterly)?", "answer": "Partial", "evidence": "RBAC + audit-log review tooling exists at /audit-logs.", "notes": "Documented quarterly access-review attestation cadence would be part of SOC 2 Type I evidence, but no audit period has started and no start date is set (see /trust/soc2)." }, { "id": "C.10", "question": "Are security roles and responsibilities documented in job descriptions?", "answer": "Partial", "notes": "Engineering job descriptions reference security ownership; formal RACI matrix planned for Q3 2026." } ] }, { "id": "D", "title": "Asset Management", "questions": [ { "id": "D.1", "question": "Do you maintain an inventory of information assets?", "answer": "Yes", "evidence": "Production assets enumerated in /docs/cmdash-aws-architecture.md and managed via Terraform (infra/terraform/). Application-level data inventory in apps/api/prisma/schema.prisma." }, { "id": "D.2", "question": "Is each asset assigned an owner?", "answer": "Yes", "evidence": "Terraform modules and code paths gated by CODEOWNERS; SOC 2 mapping CC1.5 ties owner to audit-log actorId on every state change." }, { "id": "D.3", "question": "Are assets classified by sensitivity?", "answer": "Partial", "evidence": "Internal tag taxonomy at /docs/developers/tags.md.", "notes": "Customer-data sensitivity matrix is a Q3 2026 deliverable." }, { "id": "D.4", "question": "Is hardware asset disposal performed in a way that prevents data recovery?", "answer": "Yes", "evidence": "Inherited from AWS (managed EBS/S3 lifecycle + AWS media-disposal policy). No physical hardware is owned by CMDash." }, { "id": "D.5", "question": "Do you have a documented Software Bill of Materials (SBOM) for production releases?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — a CycloneDX SBOM is generated for every release image and attached to it as a Cosign attestation signed with the release key pair." }, { "id": "D.6", "question": "Are software licenses tracked and inventoried?", "answer": "Yes", "evidence": "License inventory generated as part of the SBOM (CycloneDX includes license metadata)." }, { "id": "D.7", "question": "Are mobile devices managed (MDM)?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "D.8", "question": "Are all production assets located in approved geographies?", "answer": "Yes", "evidence": "All production processing in AWS us-east-1; subprocessor regions enumerated at /trust/subprocessors." }, { "id": "D.9", "question": "Do you maintain an inventory of cryptographic keys and their owners?", "answer": "Partial", "evidence": "Deployment secrets, including the audit-chain and license Ed25519 signing keys, are held in AWS Secrets Manager with explicit named entries (infra/terraform/lightsail-saas/secrets.tf), not AWS KMS customer-managed keys — production provisions no KMS keys for customer data. No centralized cryptographic-key inventory with automatic rotation exists today." }, { "id": "D.10", "question": "Is there a process to detect unauthorized changes to assets?", "answer": "Partial", "evidence": "The application's audit_logs table records actor identity on every state change. No AWS CloudTrail or AWS Config is deployed to detect AWS-side infrastructure changes, and no automated Terraform drift-detection job was found in this repository." } ] }, { "id": "E", "title": "Human Resources Security", "questions": [ { "id": "E.1", "question": "Do all personnel undergo background checks before hire?", "answer": "No", "notes": "CMDash currently has a single maintainer and operates no formal background-screening programme." }, { "id": "E.2", "question": "Are confidentiality and non-disclosure agreements signed by all personnel?", "answer": "Yes", "notes": "PIIA + confidentiality clauses are part of the standard offer letter for FTE; contractor MSA covers contractors." }, { "id": "E.3", "question": "Is annual security-awareness training mandatory?", "answer": "Yes", "evidence": "Annual refresh tracked as a calendar item; onboarding requires reading /docs/security/* and the secret-leak runbook." }, { "id": "E.4", "question": "Do personnel with privileged access undergo additional training?", "answer": "Yes", "evidence": "Production-access onboarding requires runbook walkthrough and on-call shadowing (cf. /docs/runbooks/)." }, { "id": "E.5", "question": "Is access reviewed and updated on role changes?", "answer": "Yes", "evidence": "Internal-RBAC role updates trigger SCIM provisioning changes (apps/api/src/saml/scim.controller.ts); LDAP-sync reflects HR-system updates." }, { "id": "E.6", "question": "Is access promptly removed upon termination?", "answer": "Yes", "evidence": "SCIM v2 DELETE on Users; refresh-token revocation invalidates active sessions within rotation window. SOC 2 mapping CC6.3." }, { "id": "E.7", "question": "Are personnel permitted to use unmanaged personal devices for work?", "answer": "Partial", "notes": "Production access is not technically restricted by device, because there is no managed-device enrolment. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "E.8", "question": "Is there a formal exit interview process that includes asset return and access removal?", "answer": "Yes", "notes": "HR-owned offboarding checklist covers asset return, SSO + GitHub + AWS access removal." } ] }, { "id": "F", "title": "Physical & Environmental Security", "questions": [ { "id": "F.1", "question": "Are production systems hosted in a physically secure facility?", "answer": "Yes", "evidence": "Hosted entirely on AWS (us-east-1). Inherited from AWS SOC 2 Type II / ISO 27001 / PCI-DSS attestations. See https://aws.amazon.com/compliance/." }, { "id": "F.2", "question": "Is physical access to production facilities restricted, logged, and reviewed?", "answer": "Yes", "evidence": "Inherited from AWS. CMDash operates no on-prem datacenters or colos." }, { "id": "F.3", "question": "Are environmental controls (fire, flood, HVAC, power) in place at hosting facilities?", "answer": "Yes", "evidence": "Inherited from AWS shared-responsibility model." }, { "id": "F.4", "question": "Are visitors logged and escorted in any office that processes company data?", "answer": "Yes", "notes": "Office is a small, badged-access workspace; no production data is processed locally (laptops connect via VPN/SSO to AWS)." }, { "id": "F.5", "question": "Is media containing customer data sanitized before disposal or reuse?", "answer": "Yes", "evidence": "All customer data lives on AWS-managed media (EBS, S3); media-disposal handled by AWS per their compliance attestations." }, { "id": "F.6", "question": "Are employee laptops encrypted at rest?", "answer": "No", "notes": "CMDash does not currently enforce or centrally verify workstation disk encryption through device management." }, { "id": "F.7", "question": "Is there a documented clean-desk policy?", "answer": "Partial", "notes": "Implicit in the AUP; standalone clean-desk policy document is a Q3 2026 SOC 2 evidence-build deliverable." }, { "id": "F.8", "question": "Are workstation screens auto-locked after inactivity?", "answer": "No", "notes": "Screen-lock timeouts are not centrally enforced; CMDash does not operate a managed-device programme." } ] }, { "id": "G", "title": "Communications & Operations Management", "questions": [ { "id": "G.1", "question": "Is there a documented production change-management process?", "answer": "Partial", "evidence": "SOC 2 mapping CC8. Every change is committed with a conventional-commit message and runs through the automated gates (lint, typecheck, tests, secret scan); main blocks force-pushes. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2). Schema migrations under apps/api/prisma/migrations/." }, { "id": "G.2", "question": "Are development, test, and production environments segregated?", "answer": "No", "evidence": "No separate AWS accounts per environment were found in this repository's infrastructure code — production is one Lightsail-based AWS footprint (infra/terraform/lightsail-saas/). SSH is currently open on production instances, restricted to admin CIDRs, not SSM-Session-Manager-only (see N.5)." }, { "id": "G.3", "question": "Is anti-malware deployed on endpoints and servers?", "answer": "Partial", "notes": "CMDash does not operate a managed-endpoint programme. Server-side AV is not deployed on the immutable container images that run in production (AWS Lightsail, not Fargate); container-image scanning (Trivy) runs in the release process per /docs/security/supply-chain.md." }, { "id": "G.4", "question": "Are system clocks synchronized to a reliable time source?", "answer": "Partial", "evidence": "Production does not run AWS Fargate, so the container-host clock-sync claim as previously stated does not apply. AWS EC2-family instances (including Lightsail) synchronize to the Amazon Time Sync Service by default; this repository does not separately document or verify that configuration." }, { "id": "G.5", "question": "Are backups taken regularly, encrypted, and tested for restoration?", "answer": "Partial", "evidence": "The managed database takes automated daily snapshots with point-in-time recovery (infra/terraform/lightsail-saas/database.tf) — not RDS, and not KMS-encrypted per this repository's documented configuration (see D.9). Backup restoration has not been drill-tested — a documented monthly restore drill is an open item (/trust/security).", "notes": "Documented monthly restore-drill cadence is an open SOC 2 evidence item (CC7.5 in /docs/compliance/soc2-type-ii-controls-mapping.md)." }, { "id": "G.6", "question": "Are application and infrastructure logs centralized?", "answer": "Partial", "evidence": "/docs/developers/structured-logging.md — pino JSON logs with consistent request/tenant/user/trace context. No third-party log or APM vendor receives application telemetry; the observability stack (Prometheus, Loki, Tempo) is self-hosted." }, { "id": "G.7", "question": "Are logs protected from tampering?", "answer": "Partial", "evidence": "No third-party log vendor holds application logs. No AWS CloudTrail is deployed, so AWS-management-plane actions have no separate tamper-evident log here." }, { "id": "G.8", "question": "Are capacity and performance monitored against documented thresholds?", "answer": "Yes", "evidence": "/docs/sre/slos.md — SLO definitions with fast- and slow-burn alerts (S39 + S45 Grafana dashboards)." }, { "id": "G.9", "question": "Are system administration activities logged with operator identity?", "answer": "Partial", "evidence": "The application's audit_logs table records actorId on every state change. No AWS CloudTrail or AWS Systems Manager Session Manager logging was found in this repository for infrastructure-level administrative actions (cloud console or SSH access)." }, { "id": "G.10", "question": "Are external-facing services protected by a Web Application Firewall?", "answer": "No", "evidence": "A WAF is written (infra/terraform/waf.tf) but that Terraform stack has never been applied (infra/terraform/README.md) — production (infra/terraform/lightsail-saas/) has no WAF. Not yet scheduled." }, { "id": "G.11", "question": "Are administrative interfaces restricted to specific source IPs or VPN?", "answer": "Partial", "evidence": "SSH access to production instances is restricted to operator-supplied admin CIDRs (infra/terraform/lightsail-saas/main.tf) — it is not SSM-Session-Manager-only; that is a documented future improvement, not the current state. This repository does not document how AWS console access itself is restricted (e.g. SSO/MFA). Database access has no public endpoint." } ] }, { "id": "H", "title": "Access Control", "questions": [ { "id": "H.1", "question": "Are unique user IDs assigned to every individual?", "answer": "Yes", "evidence": "Every user has a UUID + unique email; shared accounts are explicitly disallowed in the AUP. apps/api/src/auth/." }, { "id": "H.2", "question": "Are passwords stored using a strong one-way hash with salt?", "answer": "Yes", "evidence": "/docs/security/authentication.md — bcrypt cost factor 12 with per-user salt." }, { "id": "H.3", "question": "Is the password policy compliant with NIST 800-63B?", "answer": "Partial", "evidence": "/docs/security/authentication.md — 8-character minimum and 72-character maximum on register and reset, no composition rules by default, no forced rotation. There is no breached-password check today." }, { "id": "H.4", "question": "Is multi-factor authentication available for all users?", "answer": "Yes", "evidence": "TOTP MFA with recovery codes available to all users; SAML SSO supports IdP-side MFA. /docs/security/authentication.md." }, { "id": "H.5", "question": "Is MFA enforced for administrative and privileged users?", "answer": "Yes", "evidence": "S40 mfaPolicy gate enforces MFA for any user with admin/owner role; gate cannot be bypassed without role downgrade." }, { "id": "H.6", "question": "Are failed login attempts rate-limited or locked out?", "answer": "Yes", "evidence": "Timing-equalised login prevents account-enumeration, plus NestJS ThrottlerGuard rate-limits failed-credential bursts on auth endpoints (e.g. 20 attempts/60s per IP on login) — apps/api/src/auth/auth.controller.ts. No AWS WAF is deployed in production today." }, { "id": "H.7", "question": "Are sessions invalidated on password change or MFA disable?", "answer": "Yes", "evidence": "S38-K3 session invalidation: refresh tokens are revoked on password reset and on MFA disable. /docs/security/authentication.md." }, { "id": "H.8", "question": "Is role-based access control enforced application-side?", "answer": "Yes", "evidence": "RBAC with Owner/Admin/Viewer + custom roles. Per-tenant Postgres row-level-security policies under apps/api/prisma/migrations/*rls*. SOC 2 mapping CC6.1." }, { "id": "H.9", "question": "Is least-privilege applied to access grants?", "answer": "Yes", "evidence": "Default role on invite is Viewer; all role escalations require an Owner action recorded in audit_logs." }, { "id": "H.10", "question": "Is privileged access reviewed at least quarterly?", "answer": "Partial", "notes": "Tooling exists (audit-logs view + RBAC inspector); documented quarterly attestation cadence would be part of SOC 2 Type I evidence, but no audit period has started and no start date is set (see /trust/soc2)." }, { "id": "H.11", "question": "Are API tokens scoped, expirable, and revocable?", "answer": "Yes", "evidence": "S41 API-key TTL: every API key has an expiry; per-token scope; revocation via the API-key admin UI; revocation propagates within the cache window." }, { "id": "H.12", "question": "Is SSO supported for enterprise customers?", "answer": "Yes", "evidence": "SAML 2.0 SSO with SP-init and IdP-init flows; SCIM v2 provisioning at apps/api/src/saml/scim.controller.ts. SOC 2 mapping CC6.2." } ] }, { "id": "I", "title": "Information Systems Acquisition, Development & Maintenance", "questions": [ { "id": "I.1", "question": "Is there a documented secure software development lifecycle (SDLC)?", "answer": "Yes", "evidence": "Automated gates (lint, typecheck, tests, secret scan, dependency audit) run in the maintainer's local pre-push and release gate and in GitHub CI where enabled. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2)." }, { "id": "I.2", "question": "Are security requirements considered in design and architecture review?", "answer": "Yes", "evidence": "/architecture/ ADR-style decisions; debt ledger captures security caveats explicitly; security-impacting changes flagged in PR template." }, { "id": "I.3", "question": "Is static application security testing (SAST) integrated into CI?", "answer": "Yes", "evidence": "GitHub CodeQL on pushes + PRs; ESLint security rules; secret-scan gate blocks known-format leaks (S38-K1)." }, { "id": "I.4", "question": "Is software composition analysis (SCA) performed on dependencies?", "answer": "Yes", "evidence": "/docs/developers/dependency-updates.md — Renovate auto-PRs with severity-based merge cadence; CycloneDX SBOM published per release." }, { "id": "I.5", "question": "Are container images scanned for vulnerabilities pre-deploy?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — Trivy scan of every release image before it is pushed, and a Cosign signature made with the release key pair. There is no deploy-time admission gate." }, { "id": "I.6", "question": "Are dynamic application security tests (DAST) or pen-tests performed?", "answer": "Partial", "evidence": "/trust/pentest — no third-party engagement has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled. Until the first external engagement completes, internal Burp / OWASP ZAP runs are the only DAST coverage.", "notes": "Until the first external engagement completes, internal Burp / OWASP ZAP runs are the only DAST coverage." }, { "id": "I.7", "question": "Are production deployments separated from developer workstations?", "answer": "Partial", "evidence": "Releases are built, scanned and signed by scripts/ci/release-local.sh and deployed with scripts/deploy-lightsail.sh by the maintainer from the release host; images are published to GitHub Container Registry (GHCR). There is no CI-only deploy path and no separate approver." }, { "id": "I.8", "question": "Is code signed and provenance verified at deployment time?", "answer": "No", "evidence": "Release images are scanned (Trivy) and signed by digest with a Cosign release key pair, and the SBOM is attached as a Cosign attestation (docs/security/supply-chain.md). Signatures are verified by the release script before the release tag is published, not at deployment time: there is no admission controller (production runs on Lightsail, not Kubernetes), and no SLSA provenance attestation is produced." }, { "id": "I.9", "question": "Is there a documented release process with rollback capability?", "answer": "Yes", "evidence": "Documented release process (scripts/deploy-lightsail.sh, docs/runbooks/blue-green-cutover.md) with rollback via redeploying a retained prior-release image (KEEP_COUNT=3), not blue/green ECS service-replace or a Terraform-state revert — production is AWS Lightsail, not ECS." }, { "id": "I.10", "question": "Are feature flags used to decouple deploy from release?", "answer": "Yes", "evidence": "/docs/developers/feature-flags.md — S38 LaunchDarkly-style flag service with per-tenant overrides." }, { "id": "I.11", "question": "Are idempotency mechanisms in place for state-changing API operations?", "answer": "Yes", "evidence": "/docs/developers/idempotency.md — S39 idempotency-key middleware on all mutating endpoints." } ] }, { "id": "J", "title": "Incident Event & Communications Management", "questions": [ { "id": "J.1", "question": "Do you have a documented incident response plan?", "answer": "Yes", "evidence": "/docs/runbooks/secret-leak-response.md is the canonical IR runbook. Additional service-specific runbooks under /docs/runbooks/." }, { "id": "J.2", "question": "Are incident-response roles assigned and trained?", "answer": "Partial", "evidence": "No PagerDuty or equivalent on-call paging integration exists anywhere in this repository (see P.7), so an on-call rotation cannot page from it today. This repository does not document a separate incident-commander role or its training cadence." }, { "id": "J.3", "question": "Are security incidents tracked, classified, and reported?", "answer": "Yes", "evidence": "Security incidents are classified per the IR runbook (SEV0/SEV1/SEV2); postmortems live in /docs/runbooks/." }, { "id": "J.4", "question": "Is incident-response capability tested at least annually?", "answer": "Partial", "notes": "Real incidents have exercised the runbook; formal annual tabletop exercise is a Q4 2026 commitment." }, { "id": "J.5", "question": "Do you have a documented breach-notification SLA?", "answer": "Yes", "evidence": "/trust/dpa — 72-hour confirmed-breach notification per GDPR Article 33 obligations (we are processor for customer-controller data)." }, { "id": "J.6", "question": "Is there a published responsible-disclosure / vulnerability-reporting channel?", "answer": "Yes", "evidence": "/trust/disclosure — security@cmdash.com as the reporting mailbox; 90-day coordinated-disclosure window; documented safe-harbour." }, { "id": "J.7", "question": "Do you have a funded bug-bounty program?", "answer": "No", "notes": "/trust/disclosure is honest about this — no funded bounty. Reports are acknowledged per the timelines published there." }, { "id": "J.8", "question": "Is there a documented post-incident review (postmortem) process?", "answer": "Yes", "evidence": "Blameless postmortems for SEV0/SEV1; templates in /docs/runbooks/." }, { "id": "J.9", "question": "Is forensic-evidence preservation handled per a documented procedure?", "answer": "Partial", "notes": "The application's audit_logs table with its retention policy provides the substrate (see SEF-05 in the CAIQ). No AWS CloudTrail is deployed for AWS-management-plane evidence. A documented forensic-handling procedure is a Q4 2026 deliverable." }, { "id": "J.10", "question": "Are dead-letter queues used to recover failed event-processing?", "answer": "Yes", "evidence": "/docs/developers/dead-letter.md — S40 DLQ with redrive UI under /admin; failed events surface for IR review rather than being silently dropped." } ] }, { "id": "K", "title": "Business Continuity & Disaster Recovery", "questions": [ { "id": "K.1", "question": "Do you have a documented business-continuity plan?", "answer": "Partial", "evidence": "Operational continuity covered by /docs/cloud-deployment-runbook.md and /docs/sre/slos.md.", "notes": "Standalone customer-facing BCP document is a Q3 2026 deliverable." }, { "id": "K.2", "question": "Are RTO and RPO defined for tier-1 services?", "answer": "Yes", "evidence": "/docs/sre/slos.md — RTO 4h, RPO 15m for tier-1 surfaces (auth + core API)." }, { "id": "K.3", "question": "Are backups stored in a geographically-separate location?", "answer": "No", "evidence": "Production is single-region (us-east-1). There is no secondary AWS region and no cross-region replication for database snapshots or S3 objects — see Subprocessors." }, { "id": "K.4", "question": "Are restoration procedures tested at least annually?", "answer": "Partial", "notes": "Ad-hoc restore tests have been performed; documented monthly cadence is open SOC 2 evidence item (CC7.5)." }, { "id": "K.5", "question": "Are graceful-degradation patterns implemented for downstream-dependency failures?", "answer": "Yes", "evidence": "/docs/developers/circuit-breaker.md — S40 circuit breaker around third-party HTTP calls; /docs/developers/dead-letter.md for async." }, { "id": "K.6", "question": "Is there documented multi-AZ deployment for production?", "answer": "Partial", "evidence": "Production runs on AWS Lightsail, not RDS/ECS/ALB. Application instances are distributed across availability zones behind a Lightsail load balancer, and the managed database is provisioned on a high-availability bundle by default (infra/terraform/lightsail-saas/). Not independently confirmed against the live deployment’s Terraform state, which is not committed to this repository." }, { "id": "K.7", "question": "Is there a status page that customers can subscribe to?", "answer": "Partial", "evidence": "/docs/status-page-setup.md describes the planned status page (Statuspage.io)." }, { "id": "K.8", "question": "Are SLA credits documented and contractually committed?", "answer": "Yes", "notes": "99.9% monthly availability SLA committed in the Master Services Agreement; credit schedule attached to the order form." }, { "id": "K.9", "question": "Have you experienced any unplanned downtime exceeding the SLA in the last 12 months?", "answer": "No", "notes": "No SLA-breaching incidents in the trailing 12 months. Postmortems for sub-SLA incidents available under NDA on request." } ] }, { "id": "L", "title": "Compliance", "questions": [ { "id": "L.1", "question": "Are you SOC 2 Type II attested?", "answer": "No", "notes": "/trust/soc2 — no SOC 2 report and no auditor engaged yet. No audit period has started, and no start date is set. Per-CC readiness self-assessment mapped at /docs/compliance/soc2-type-ii-controls-mapping.md." }, { "id": "L.2", "question": "Are you ISO/IEC 27001 certified?", "answer": "No", "notes": "On the roadmap post-SOC 2 Type II. No engagement letter yet." }, { "id": "L.3", "question": "Are you HIPAA-compliant for handling PHI?", "answer": "No", "notes": "We do not contractually accept PHI today. Customers handling PHI are advised not to upload it." }, { "id": "L.4", "question": "Are you GDPR-compliant?", "answer": "Yes", "evidence": "/trust/dpa — GDPR Article 28 processor obligations; SCC + BCR transfer mechanisms; 72-hour breach notification; legal@cmdash.com for DPA execution." }, { "id": "L.5", "question": "Are you CCPA/CPRA-compliant?", "answer": "Yes", "notes": "We are a Service Provider under CCPA; the standard MSA + DPA includes the CCPA service-provider language. Data-subject-rights tooling lives at /apps/web/src/app/(dashboard)/data-export/." }, { "id": "L.6", "question": "Are you PCI-DSS in scope?", "answer": "No", "notes": "We do not store, process or transmit cardholder data. Stripe handles all payment-card data as a PCI-DSS Level 1 service provider; CMDash receives only tokenized references." }, { "id": "L.7", "question": "Are you FedRAMP-authorized?", "answer": "No", "notes": "CMDash is not FedRAMP-authorized." }, { "id": "L.8", "question": "Are you HITRUST-certified?", "answer": "No", "notes": "Not pursued; no engagement letter." }, { "id": "L.9", "question": "Do you support customer-controlled data residency?", "answer": "No", "notes": "All production processing in AWS us-east-1. EU residency is a 2027 roadmap item; until then, EU-customer deployments rely on the SCC mechanism documented at /trust/dpa." }, { "id": "L.10", "question": "Do you map your controls to a recognized framework?", "answer": "Yes", "evidence": "SOC 2 (CC1-CC9 + A1) at /docs/compliance/soc2-type-ii-controls-mapping.md; Cloud Controls Matrix v4 mapping via this CAIQ at /docs/compliance/questionnaires/caiq-v4-2026.json." } ] }, { "id": "M", "title": "End-User Device Security", "questions": [ { "id": "M.1", "question": "Are end-user devices that access production data centrally managed?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.2", "question": "Is full-disk encryption enforced on end-user devices?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.3", "question": "Is anti-malware deployed on end-user devices?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.4", "question": "Are screen-lock timeouts enforced?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.5", "question": "Are unauthorized USB / removable-media uses controlled?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.6", "question": "Are local administrator privileges restricted?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.7", "question": "Is patching automated on end-user devices?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "M.8", "question": "Can devices be remotely wiped on loss/theft?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." } ] }, { "id": "N", "title": "Network Security", "questions": [ { "id": "N.1", "question": "Are network boundaries protected with firewalls?", "answer": "Partial", "evidence": "AWS Lightsail instance firewall rules restrict inbound access (e.g. SSH limited to admin CIDRs, infra/terraform/lightsail-saas/main.tf), and a Lightsail load balancer terminates public traffic. This is Lightsail’s own networking model, not VPC Security Groups/Network ACLs, and there is no WAF in front of it — see G.10." }, { "id": "N.2", "question": "Is TLS 1.2+ enforced for all customer-facing endpoints?", "answer": "No", "evidence": "Production's load balancer currently accepts TLS 1.0 and 1.1 in addition to 1.2, and refuses TLS 1.3 (verified against production, 2026-09-25). There is no ALB — this is a Lightsail load-balancer certificate with no minimum-version policy set. The HSTS header requests preload, but neither cmdash.com nor cmdash.net has been submitted to the browser preload list, so preload is not in effect." }, { "id": "N.3", "question": "Are weak ciphers and protocols disabled?", "answer": "No", "evidence": "No ALB or ELBSecurityPolicy is in use. Production runs a Lightsail load balancer with no documented cipher/protocol restriction in this repository's Terraform, and TLS 1.0/1.1 are still accepted today — see N.2." }, { "id": "N.4", "question": "Are HTTP security headers set per OWASP guidance?", "answer": "Partial", "evidence": "/docs/security/http-headers.md — headers are set by the Next.js applications and by helmet in the API (Caddy is the edge proxy); CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are set on the dashboard, marketing site and API. The policy portal sets only X-Content-Type-Options, X-Frame-Options and Referrer-Policy, and the staff admin app's CSP still allows unsafe-inline and unsafe-eval." }, { "id": "N.5", "question": "Are management protocols (SSH, RDP) restricted to approved sources?", "answer": "No", "evidence": "SSH is currently open on production instances, restricted to operator-supplied admin CIDRs (infra/terraform/lightsail-saas/main.tf) — it is not SSM-Session-Manager-only. That file's own comment names moving to AWS SSM / Session Manager, so no inbound SSH port is exposed, as a longer-term improvement, not the current state." }, { "id": "N.6", "question": "Is network traffic between application and database encrypted?", "answer": "Yes", "notes": "Database connections use TLS with certificate validation; the application enforces sslmode=require. Production runs a Lightsail managed PostgreSQL database, not RDS." }, { "id": "N.7", "question": "Are intrusion-detection or anomaly-detection systems deployed?", "answer": "No", "evidence": "No AWS GuardDuty is deployed. An application-level AnomalyEvent mechanism exists (apps/api/src/anomaly-detection/) but it tracks tenant posture-score and risk-count drift, not security/intrusion signals such as login anomalies — see /trust/security." }, { "id": "N.8", "question": "Is DDoS protection in place?", "answer": "Partial", "notes": "No AWS WAF is deployed (see G.10). AWS Shield Standard is automatically included at no charge for public AWS endpoints. No Shield Advanced upgrade plan or date was found in this repository.", "evidence": "AWS Shield Standard is automatically included at no charge for public AWS endpoints, including this deployment's. No AWS WAF is deployed (see G.10), so there are no WAF rate-based rules absorbing application-layer floods. No Shield Advanced upgrade plan or date was found in this repository." }, { "id": "N.9", "question": "Are network changes reviewed before deployment?", "answer": "Partial", "evidence": "Infrastructure changes are made as Terraform code (infra/terraform/lightsail-saas/) and reviewed by the maintainer before apply. Production uses Lightsail networking, with no VPC, Security Groups or Network ACLs. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2)." }, { "id": "N.10", "question": "Are DNS records protected with DNSSEC and CAA?", "answer": "No", "notes": "No CAA records are published for cmdash.com or cmdash.net." } ] }, { "id": "O", "title": "Privacy", "questions": [ { "id": "O.1", "question": "Do you publish a public privacy notice?", "answer": "Yes", "evidence": "/trust covers the program-level summary; a standalone Privacy Notice URL is maintained on the marketing site." }, { "id": "O.2", "question": "Do you offer a Data Processing Addendum (DPA)?", "answer": "Yes", "evidence": "/trust/dpa — GDPR Article 28-compliant DPA with SCC and BCR fallback; legal@cmdash.com for execution." }, { "id": "O.3", "question": "Do you support data-subject access, deletion, and portability requests?", "answer": "Yes", "evidence": "/apps/web/src/app/(dashboard)/data-export/ — self-serve export and deletion tooling for tenant administrators." }, { "id": "O.4", "question": "Do you minimize the personal data you collect?", "answer": "Yes", "evidence": "Schema review during design phase rejects collection without a documented purpose. PII fields tagged in apps/api/prisma/schema.prisma." }, { "id": "O.5", "question": "Are international data transfers governed by an approved mechanism?", "answer": "Yes", "evidence": "/trust/dpa — Standard Contractual Clauses (SCC) for EU/UK transfers; Binding Corporate Rules (BCR) fallback documented." }, { "id": "O.6", "question": "Do you maintain a record of processing activities (RoPA)?", "answer": "Partial", "evidence": "Subprocessor list at /trust/subprocessors covers data categories per processor.", "notes": "Standalone RoPA register is a Q3 2026 deliverable as part of SOC 2 + GDPR maturation." }, { "id": "O.7", "question": "Have you appointed a Data Protection Officer (DPO) or EU representative where required?", "answer": "Partial", "notes": "DPO not formally appointed (we fall under the GDPR Art 37 voluntary-appointment threshold). EU-representative appointment will be triggered by first EEA-customer onboarding." }, { "id": "O.8", "question": "Do you notify customers of changes to subprocessors before they take effect?", "answer": "Yes", "evidence": "/trust/subprocessors — 30-day change-notification policy with email alert to the security contact on file." }, { "id": "O.9", "question": "Do you support customer-controlled retention periods?", "answer": "Yes", "evidence": "/apps/web/src/app/(dashboard)/data-retention/ — per-tenant retention policy configuration." }, { "id": "O.10", "question": "Do you sell personal data to third parties?", "answer": "No", "notes": "CMDash does not sell personal data. The MSA + DPA contractually prohibit any such use." } ] }, { "id": "P", "title": "Threat Management", "questions": [ { "id": "P.1", "question": "Do you maintain a threat model for the application?", "answer": "Yes", "evidence": "/architecture/ ADRs include explicit threat-model sections for high-risk surfaces (auth, multi-tenancy, supply chain)." }, { "id": "P.2", "question": "Are vulnerabilities tracked with severity-based remediation SLAs?", "answer": "Yes", "evidence": "/trust/pentest — Critical 7d (or a mitigating control within 48h) / High 30d / Medium 60d / Low/Informational 90d or a written rationale. Dependency CVEs auto-PR'd." }, { "id": "P.3", "question": "Are CVEs in third-party dependencies monitored continuously?", "answer": "Yes", "evidence": "/docs/developers/dependency-updates.md — Renovate + GitHub Dependabot; severity-based merge cadence; CycloneDX SBOM published per release." }, { "id": "P.4", "question": "Do you participate in or monitor threat-intelligence feeds?", "answer": "Partial", "notes": "Subscribed to the CSA threat-intel circular and CVE.org feed; ISAC/ISAO membership not yet pursued." }, { "id": "P.5", "question": "Are penetration tests performed at least annually?", "answer": "No", "notes": "/trust/pentest — no third-party penetration test has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled. Will become an annual cadence after the first engagement.", "evidence": "/trust/pentest — no third-party penetration test has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled. Will become an annual cadence after the first engagement." }, { "id": "P.6", "question": "Are supply-chain attacks (typosquat, dependency confusion) mitigated?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — internal scope on @cmdash/* packages; release images signed with a Cosign release key pair. No SLSA provenance attestation is produced." }, { "id": "P.7", "question": "Is there an alerting pipeline for security-relevant events?", "answer": "No", "evidence": "No AWS GuardDuty is deployed, and no PagerDuty or equivalent on-call paging integration exists anywhere in this repository. CloudWatch alarms and SNS paging for the cloud deployment are written but not yet applied to production — see /trust/security." }, { "id": "P.8", "question": "Are webhooks and inbound integrations authenticated and verified?", "answer": "Yes", "evidence": "/docs/developers/webhook-receivers.md — HMAC-SHA256 signature verification, replay protection via timestamp + nonce, sender-IP allowlist where the provider supports it." }, { "id": "P.9", "question": "Do you track and observe end-to-end traces in production?", "answer": "Yes", "evidence": "/docs/developers/structured-logging.md — S41 + S45 W3C trace-context propagation across services and into webhook deliveries." } ] } ] }