CMDashTrust Center

Trust Center / Questionnaires

Pre-filled questionnaires

Most enterprise security reviews ask for a Shared Assessments SIG Lite spreadsheet and a Cloud Security Alliance CAIQ v4 spreadsheet. If your review covers our use of AI specifically, we also publish a CSA AI-CAIQ v1.1 self-assessment and an OWASP LLM Top 10 (2025) self-assessment. We maintain pre-filled, dated answer sets for all four. Each "Yes" cites the shipped artifact (doc, code module, or other Trust Center page) it relies on. Each "No" states the planned remediation.

These answer sets are being re-verified. Some answers state dates and plans that are not confirmed yet, so treat an answer as a starting point, not a commitment.

The JSON below is the authoritative source. Download it, or read inline. For a custom spreadsheet, an XLSX export, or a questionnaire template we don’t list, email security@cmdash.com.

Available questionnaires

SIG Lite(2026)

CMDash multi-tenant SaaS platform, hosted on AWS us-east-1. Excludes on-prem self-hosted deployments which inherit the customer's own controls.

Questions
156
Yes
49%
No
24%
NA / Partial / Compensating
27%

ARisk Management & Risk Assessment

  1. A.1

    Do you have a documented information security program?

    Yes

    Evidence: /docs/compliance/soc2-type-ii-controls-mapping.md (CC1-CC9 + A1 trust criteria mapping). Public summary at /trust/security.

  2. A.2

    Is the information security program approved by executive management and reviewed at least annually?

    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).

  3. A.3

    Do you maintain a formal risk register identifying threats, likelihoods and impacts?

    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.

  4. A.4

    Are risks reassessed when significant changes occur (architecture, vendors, regulation)?

    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.

  5. A.5

    Do you maintain a formal risk-treatment plan with owners and target dates?

    Yes

    Evidence: /docs/improvement-catalog.md groups remediations by sprint and owner; debt ledger tracks dated caveats.

  6. A.6

    Do you have a documented and tested business impact analysis (BIA)?

    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).

  7. A.7

    Do you carry cyber-liability insurance?

    No

    Notes: CMDash does not currently carry a cyber-liability insurance policy.

  8. A.8

    Do you perform formal vendor risk assessments before onboarding subprocessors?

    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.

  9. A.9

    Are residual risks formally accepted by the risk owner?

    Yes

    Evidence: Debt-ledger entries (architecture/09-known-debt.md) require a named owner and a target sprint or 'accepted residual' tag.

  10. A.10

    Do you have ISO 27001 certification?

    No

    Notes: ISO 27001 is on the roadmap post-SOC 2 Type II attestation. Not currently certified; no scheduled audit.

BSecurity Policies & Procedures

  1. B.1

    Do you have a written information security policy reviewed at least annually?

    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.

  2. B.2

    Is there a formal acceptable-use policy for all personnel?

    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.

  3. B.3

    Are policies communicated to all employees and contractors?

    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.

  4. B.4

    Do you have a documented data classification policy?

    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.

  5. B.5

    Do you have a documented data retention and disposal policy?

    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).

  6. B.6

    Are exceptions to security policies formally documented and approved?

    Yes

    Evidence: Every exception lives in architecture/09-known-debt.md as a dated caveat with a named owner.

  7. B.7

    Do you have a documented change-management policy?

    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/.

  8. B.8

    Do you have a documented vulnerability management policy with severity-based remediation SLAs?

    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.

  9. B.9

    Do you have a documented incident-response policy with defined roles?

    Yes

    Evidence: /docs/runbooks/secret-leak-response.md is the canonical IR runbook; on-call rotation owns initial triage.

  10. B.10

    Are policies version-controlled with an audit trail?

    Yes

    Evidence: All policies live in this git repo; full author + date history available via git log on /docs/security/, /docs/compliance/, /docs/runbooks/.

COrganizational Security

  1. C.1

    Is there a designated CISO or security lead with executive accountability?

    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.

  2. C.2

    Are security responsibilities segregated from operational duties where appropriate?

    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).

  3. C.3

    Are personnel screened (background check) before being granted access to customer data?

    No

    Notes: CMDash currently has a single maintainer and operates no formal background-screening programme.

  4. C.4

    Do contractors and temporary workers sign confidentiality agreements?

    Yes

    Notes: Contractor MSA includes NDA + confidentiality clauses; legal@cmdash.com owns the template.

  5. C.5

    Is there a formal security-awareness training program for all personnel?

    Yes

    Evidence: Onboarding requires reading /docs/security/* and /docs/runbooks/secret-leak-response.md. Annual refresh is a calendar event for the engineering org.

  6. C.6

    Do you have a documented disciplinary process for security-policy violations?

    Yes

    Notes: Security violations are handled under the acceptable-use expectations documented in the repository.

  7. C.7

    Is access removed within one business day of termination?

    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.

  8. C.8

    Do you maintain a documented org chart with reporting lines?

    Partial

    Notes: A formal org chart is an open management item (see /trust/soc2).

  9. C.9

    Is there a process for periodic access reviews (at least quarterly)?

    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).

  10. C.10

    Are security roles and responsibilities documented in job descriptions?

    Partial

    Notes: Engineering job descriptions reference security ownership; formal RACI matrix planned for Q3 2026.

DAsset Management

  1. D.1

    Do you maintain an inventory of information assets?

    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.

  2. D.2

    Is each asset assigned an owner?

    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.

  3. D.3

    Are assets classified by sensitivity?

    Partial

    Evidence: Internal tag taxonomy at /docs/developers/tags.md.

    Notes: Customer-data sensitivity matrix is a Q3 2026 deliverable.

  4. D.4

    Is hardware asset disposal performed in a way that prevents data recovery?

    Yes

    Evidence: Inherited from AWS (managed EBS/S3 lifecycle + AWS media-disposal policy). No physical hardware is owned by CMDash.

  5. D.5

    Do you have a documented Software Bill of Materials (SBOM) for production releases?

    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.

  6. D.6

    Are software licenses tracked and inventoried?

    Yes

    Evidence: License inventory generated as part of the SBOM (CycloneDX includes license metadata).

  7. D.7

    Are mobile devices managed (MDM)?

    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).

  8. D.8

    Are all production assets located in approved geographies?

    Yes

    Evidence: All production processing in AWS us-east-1; subprocessor regions enumerated at /trust/subprocessors.

  9. D.9

    Do you maintain an inventory of cryptographic keys and their owners?

    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.

  10. D.10

    Is there a process to detect unauthorized changes to assets?

    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.

EHuman Resources Security

  1. E.1

    Do all personnel undergo background checks before hire?

    No

    Notes: CMDash currently has a single maintainer and operates no formal background-screening programme.

  2. E.2

    Are confidentiality and non-disclosure agreements signed by all personnel?

    Yes

    Notes: PIIA + confidentiality clauses are part of the standard offer letter for FTE; contractor MSA covers contractors.

  3. E.3

    Is annual security-awareness training mandatory?

    Yes

    Evidence: Annual refresh tracked as a calendar item; onboarding requires reading /docs/security/* and the secret-leak runbook.

  4. E.4

    Do personnel with privileged access undergo additional training?

    Yes

    Evidence: Production-access onboarding requires runbook walkthrough and on-call shadowing (cf. /docs/runbooks/).

  5. E.5

    Is access reviewed and updated on role changes?

    Yes

    Evidence: Internal-RBAC role updates trigger SCIM provisioning changes (apps/api/src/saml/scim.controller.ts); LDAP-sync reflects HR-system updates.

  6. E.6

    Is access promptly removed upon termination?

    Yes

    Evidence: SCIM v2 DELETE on Users; refresh-token revocation invalidates active sessions within rotation window. SOC 2 mapping CC6.3.

  7. E.7

    Are personnel permitted to use unmanaged personal devices for work?

    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).

  8. E.8

    Is there a formal exit interview process that includes asset return and access removal?

    Yes

    Notes: HR-owned offboarding checklist covers asset return, SSO + GitHub + AWS access removal.

FPhysical & Environmental Security

  1. F.1

    Are production systems hosted in a physically secure facility?

    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/.

  2. F.2

    Is physical access to production facilities restricted, logged, and reviewed?

    Yes

    Evidence: Inherited from AWS. CMDash operates no on-prem datacenters or colos.

  3. F.3

    Are environmental controls (fire, flood, HVAC, power) in place at hosting facilities?

    Yes

    Evidence: Inherited from AWS shared-responsibility model.

  4. F.4

    Are visitors logged and escorted in any office that processes company data?

    Yes

    Notes: Office is a small, badged-access workspace; no production data is processed locally (laptops connect via VPN/SSO to AWS).

  5. F.5

    Is media containing customer data sanitized before disposal or reuse?

    Yes

    Evidence: All customer data lives on AWS-managed media (EBS, S3); media-disposal handled by AWS per their compliance attestations.

  6. F.6

    Are employee laptops encrypted at rest?

    No

    Notes: CMDash does not currently enforce or centrally verify workstation disk encryption through device management.

  7. F.7

    Is there a documented clean-desk policy?

    Partial

    Notes: Implicit in the AUP; standalone clean-desk policy document is a Q3 2026 SOC 2 evidence-build deliverable.

  8. F.8

    Are workstation screens auto-locked after inactivity?

    No

    Notes: Screen-lock timeouts are not centrally enforced; CMDash does not operate a managed-device programme.

GCommunications & Operations Management

  1. G.1

    Is there a documented production change-management process?

    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/.

  2. G.2

    Are development, test, and production environments segregated?

    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).

  3. G.3

    Is anti-malware deployed on endpoints and servers?

    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.

  4. G.4

    Are system clocks synchronized to a reliable time source?

    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.

  5. G.5

    Are backups taken regularly, encrypted, and tested for restoration?

    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).

  6. G.6

    Are application and infrastructure logs centralized?

    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.

  7. G.7

    Are logs protected from tampering?

    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.

  8. G.8

    Are capacity and performance monitored against documented thresholds?

    Yes

    Evidence: /docs/sre/slos.md — SLO definitions with fast- and slow-burn alerts (S39 + S45 Grafana dashboards).

  9. G.9

    Are system administration activities logged with operator identity?

    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).

  10. G.10

    Are external-facing services protected by a Web Application Firewall?

    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.

  11. G.11

    Are administrative interfaces restricted to specific source IPs or VPN?

    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.

HAccess Control

  1. H.1

    Are unique user IDs assigned to every individual?

    Yes

    Evidence: Every user has a UUID + unique email; shared accounts are explicitly disallowed in the AUP. apps/api/src/auth/.

  2. H.2

    Are passwords stored using a strong one-way hash with salt?

    Yes

    Evidence: /docs/security/authentication.md — bcrypt cost factor 12 with per-user salt.

  3. H.3

    Is the password policy compliant with NIST 800-63B?

    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.

  4. H.4

    Is multi-factor authentication available for all users?

    Yes

    Evidence: TOTP MFA with recovery codes available to all users; SAML SSO supports IdP-side MFA. /docs/security/authentication.md.

  5. H.5

    Is MFA enforced for administrative and privileged users?

    Yes

    Evidence: S40 mfaPolicy gate enforces MFA for any user with admin/owner role; gate cannot be bypassed without role downgrade.

  6. H.6

    Are failed login attempts rate-limited or locked out?

    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.

  7. H.7

    Are sessions invalidated on password change or MFA disable?

    Yes

    Evidence: S38-K3 session invalidation: refresh tokens are revoked on password reset and on MFA disable. /docs/security/authentication.md.

  8. H.8

    Is role-based access control enforced application-side?

    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.

  9. H.9

    Is least-privilege applied to access grants?

    Yes

    Evidence: Default role on invite is Viewer; all role escalations require an Owner action recorded in audit_logs.

  10. H.10

    Is privileged access reviewed at least quarterly?

    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).

  11. H.11

    Are API tokens scoped, expirable, and revocable?

    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.

  12. H.12

    Is SSO supported for enterprise customers?

    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.

IInformation Systems Acquisition, Development & Maintenance

  1. I.1

    Is there a documented secure software development lifecycle (SDLC)?

    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).

  2. I.2

    Are security requirements considered in design and architecture review?

    Yes

    Evidence: /architecture/ ADR-style decisions; debt ledger captures security caveats explicitly; security-impacting changes flagged in PR template.

  3. I.3

    Is static application security testing (SAST) integrated into CI?

    Yes

    Evidence: GitHub CodeQL on pushes + PRs; ESLint security rules; secret-scan gate blocks known-format leaks (S38-K1).

  4. I.4

    Is software composition analysis (SCA) performed on dependencies?

    Yes

    Evidence: /docs/developers/dependency-updates.md — Renovate auto-PRs with severity-based merge cadence; CycloneDX SBOM published per release.

  5. I.5

    Are container images scanned for vulnerabilities pre-deploy?

    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.

  6. I.6

    Are dynamic application security tests (DAST) or pen-tests performed?

    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.

  7. I.7

    Are production deployments separated from developer workstations?

    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.

  8. I.8

    Is code signed and provenance verified at deployment time?

    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.

  9. I.9

    Is there a documented release process with rollback capability?

    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.

  10. I.10

    Are feature flags used to decouple deploy from release?

    Yes

    Evidence: /docs/developers/feature-flags.md — S38 LaunchDarkly-style flag service with per-tenant overrides.

  11. I.11

    Are idempotency mechanisms in place for state-changing API operations?

    Yes

    Evidence: /docs/developers/idempotency.md — S39 idempotency-key middleware on all mutating endpoints.

JIncident Event & Communications Management

  1. J.1

    Do you have a documented incident response plan?

    Yes

    Evidence: /docs/runbooks/secret-leak-response.md is the canonical IR runbook. Additional service-specific runbooks under /docs/runbooks/.

  2. J.2

    Are incident-response roles assigned and trained?

    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.

  3. J.3

    Are security incidents tracked, classified, and reported?

    Yes

    Evidence: Security incidents are classified per the IR runbook (SEV0/SEV1/SEV2); postmortems live in /docs/runbooks/.

  4. J.4

    Is incident-response capability tested at least annually?

    Partial

    Notes: Real incidents have exercised the runbook; formal annual tabletop exercise is a Q4 2026 commitment.

  5. J.5

    Do you have a documented breach-notification SLA?

    Yes

    Evidence: /trust/dpa — 72-hour confirmed-breach notification per GDPR Article 33 obligations (we are processor for customer-controller data).

  6. J.6

    Is there a published responsible-disclosure / vulnerability-reporting channel?

    Yes

    Evidence: /trust/disclosure — security@cmdash.com as the reporting mailbox; 90-day coordinated-disclosure window; documented safe-harbour.

  7. J.7

    Do you have a funded bug-bounty program?

    No

    Notes: /trust/disclosure is honest about this — no funded bounty. Reports are acknowledged per the timelines published there.

  8. J.8

    Is there a documented post-incident review (postmortem) process?

    Yes

    Evidence: Blameless postmortems for SEV0/SEV1; templates in /docs/runbooks/.

  9. J.9

    Is forensic-evidence preservation handled per a documented procedure?

    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.

  10. J.10

    Are dead-letter queues used to recover failed event-processing?

    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.

KBusiness Continuity & Disaster Recovery

  1. K.1

    Do you have a documented business-continuity plan?

    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.

  2. K.2

    Are RTO and RPO defined for tier-1 services?

    Yes

    Evidence: /docs/sre/slos.md — RTO 4h, RPO 15m for tier-1 surfaces (auth + core API).

  3. K.3

    Are backups stored in a geographically-separate location?

    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.

  4. K.4

    Are restoration procedures tested at least annually?

    Partial

    Notes: Ad-hoc restore tests have been performed; documented monthly cadence is open SOC 2 evidence item (CC7.5).

  5. K.5

    Are graceful-degradation patterns implemented for downstream-dependency failures?

    Yes

    Evidence: /docs/developers/circuit-breaker.md — S40 circuit breaker around third-party HTTP calls; /docs/developers/dead-letter.md for async.

  6. K.6

    Is there documented multi-AZ deployment for production?

    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.

  7. K.7

    Is there a status page that customers can subscribe to?

    Partial

    Evidence: /docs/status-page-setup.md describes the planned status page (Statuspage.io).

  8. K.8

    Are SLA credits documented and contractually committed?

    Yes

    Notes: 99.9% monthly availability SLA committed in the Master Services Agreement; credit schedule attached to the order form.

  9. K.9

    Have you experienced any unplanned downtime exceeding the SLA in the last 12 months?

    No

    Notes: No SLA-breaching incidents in the trailing 12 months. Postmortems for sub-SLA incidents available under NDA on request.

LCompliance

  1. L.1

    Are you SOC 2 Type II attested?

    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.

  2. L.2

    Are you ISO/IEC 27001 certified?

    No

    Notes: On the roadmap post-SOC 2 Type II. No engagement letter yet.

  3. L.3

    Are you HIPAA-compliant for handling PHI?

    No

    Notes: We do not contractually accept PHI today. Customers handling PHI are advised not to upload it.

  4. L.4

    Are you GDPR-compliant?

    Yes

    Evidence: /trust/dpa — GDPR Article 28 processor obligations; SCC + BCR transfer mechanisms; 72-hour breach notification; legal@cmdash.com for DPA execution.

  5. L.5

    Are you CCPA/CPRA-compliant?

    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/.

  6. L.6

    Are you PCI-DSS in scope?

    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.

  7. L.7

    Are you FedRAMP-authorized?

    No

    Notes: CMDash is not FedRAMP-authorized.

  8. L.8

    Are you HITRUST-certified?

    No

    Notes: Not pursued; no engagement letter.

  9. L.9

    Do you support customer-controlled data residency?

    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.

  10. L.10

    Do you map your controls to a recognized framework?

    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.

MEnd-User Device Security

  1. M.1

    Are end-user devices that access production data centrally managed?

    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).

  2. M.2

    Is full-disk encryption enforced on end-user devices?

    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).

  3. M.3

    Is anti-malware deployed on end-user devices?

    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).

  4. M.4

    Are screen-lock timeouts enforced?

    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).

  5. M.5

    Are unauthorized USB / removable-media uses controlled?

    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).

  6. M.6

    Are local administrator privileges restricted?

    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).

  7. M.7

    Is patching automated on end-user devices?

    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).

  8. M.8

    Can devices be remotely wiped on loss/theft?

    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).

NNetwork Security

  1. N.1

    Are network boundaries protected with firewalls?

    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.

  2. N.2

    Is TLS 1.2+ enforced for all customer-facing endpoints?

    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.

  3. N.3

    Are weak ciphers and protocols disabled?

    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.

  4. N.4

    Are HTTP security headers set per OWASP guidance?

    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.

  5. N.5

    Are management protocols (SSH, RDP) restricted to approved sources?

    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.

  6. N.6

    Is network traffic between application and database encrypted?

    Yes

    Notes: Database connections use TLS with certificate validation; the application enforces sslmode=require. Production runs a Lightsail managed PostgreSQL database, not RDS.

  7. N.7

    Are intrusion-detection or anomaly-detection systems deployed?

    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.

  8. N.8

    Is DDoS protection in place?

    Partial

    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.

    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.

  9. N.9

    Are network changes reviewed before deployment?

    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).

  10. N.10

    Are DNS records protected with DNSSEC and CAA?

    No

    Notes: No CAA records are published for cmdash.com or cmdash.net.

OPrivacy

  1. O.1

    Do you publish a public privacy notice?

    Yes

    Evidence: /trust covers the program-level summary; a standalone Privacy Notice URL is maintained on the marketing site.

  2. O.2

    Do you offer a Data Processing Addendum (DPA)?

    Yes

    Evidence: /trust/dpa — GDPR Article 28-compliant DPA with SCC and BCR fallback; legal@cmdash.com for execution.

  3. O.3

    Do you support data-subject access, deletion, and portability requests?

    Yes

    Evidence: /apps/web/src/app/(dashboard)/data-export/ — self-serve export and deletion tooling for tenant administrators.

  4. O.4

    Do you minimize the personal data you collect?

    Yes

    Evidence: Schema review during design phase rejects collection without a documented purpose. PII fields tagged in apps/api/prisma/schema.prisma.

  5. O.5

    Are international data transfers governed by an approved mechanism?

    Yes

    Evidence: /trust/dpa — Standard Contractual Clauses (SCC) for EU/UK transfers; Binding Corporate Rules (BCR) fallback documented.

  6. O.6

    Do you maintain a record of processing activities (RoPA)?

    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.

  7. O.7

    Have you appointed a Data Protection Officer (DPO) or EU representative where required?

    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.

  8. O.8

    Do you notify customers of changes to subprocessors before they take effect?

    Yes

    Evidence: /trust/subprocessors — 30-day change-notification policy with email alert to the security contact on file.

  9. O.9

    Do you support customer-controlled retention periods?

    Yes

    Evidence: /apps/web/src/app/(dashboard)/data-retention/ — per-tenant retention policy configuration.

  10. O.10

    Do you sell personal data to third parties?

    No

    Notes: CMDash does not sell personal data. The MSA + DPA contractually prohibit any such use.

PThreat Management

  1. P.1

    Do you maintain a threat model for the application?

    Yes

    Evidence: /architecture/ ADRs include explicit threat-model sections for high-risk surfaces (auth, multi-tenancy, supply chain).

  2. P.2

    Are vulnerabilities tracked with severity-based remediation SLAs?

    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.

  3. P.3

    Are CVEs in third-party dependencies monitored continuously?

    Yes

    Evidence: /docs/developers/dependency-updates.md — Renovate + GitHub Dependabot; severity-based merge cadence; CycloneDX SBOM published per release.

  4. P.4

    Do you participate in or monitor threat-intelligence feeds?

    Partial

    Notes: Subscribed to the CSA threat-intel circular and CVE.org feed; ISAC/ISAO membership not yet pursued.

  5. P.5

    Are penetration tests performed at least annually?

    No

    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.

    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.

  6. P.6

    Are supply-chain attacks (typosquat, dependency confusion) mitigated?

    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.

  7. P.7

    Is there an alerting pipeline for security-relevant events?

    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.

  8. P.8

    Are webhooks and inbound integrations authenticated and verified?

    Yes

    Evidence: /docs/developers/webhook-receivers.md — HMAC-SHA256 signature verification, replay protection via timestamp + nonce, sender-IP allowlist where the provider supports it.

  9. P.9

    Do you track and observe end-to-end traces in production?

    Yes

    Evidence: /docs/developers/structured-logging.md — S41 + S45 W3C trace-context propagation across services and into webhook deliveries.

Need a custom questionnaire or an XLSX export?

The JSON above is the authoritative answer set; the same content is also maintained at /trust/security and the rest of the Trust Center. For a custom spreadsheet, regulator-specific overlay, or to request the XLSX export, email security@cmdash.com.

Request a completed questionnaire

Pick a format below. The four we already publish are filled and sent automatically; anything else goes to a human.

Which questionnaire?