Consensus Assessments Initiative Questionnaire.

A structured control self-assessment runs through our GRC platform (GOCO); we do not yet have an independent internal audit function. The first independent assessment will be the SOC 2 Type I engagement.

SOC 2 Type I is in progress (policies written and approved, controls mapped and evidenced, auditor selection underway) but not yet issued.

A SOC 2 Type I readiness risk assessment was performed and a risk register is maintained with named risks and disposition status.

Will be available under NDA once SOC 2 Type I is issued. Not yet available because the report does not yet exist.

Ten written, founder-approved security policies cover access management, incident response, data classification, business continuity, vendor risk, change control, and more.

Formal policy set approved and dated; a semiannual internal review cadence (Jan/Jul) is documented for audit-log and program review.

Role-based access (Owner / Member / Survey Collaborator as Editor or Viewer), enforced at the database layer via Postgres Row-Level Security, not only in application code.

Every change to production requires a pull request, review by a second engineer, and passing automated checks (ESLint, TypeScript, dependency vulnerability audit) before merge.

TLS 1.2+ enforced on all connections, with HTTP Strict Transport Security (HSTS) preventing any unencrypted fallback, including on first visit.

No third-party penetration test has been performed to date. Current coverage is limited to static analysis (lint/typecheck) and automated dependency scanning. Tracked as an open item.

GitHub branch protection on `main` requires PR review and passing status checks; verified enabled and confirmed via the GitHub API and dashboard.

All API routes and server actions validate input server-side; database access goes through the Supabase client with RLS rather than raw interpolated SQL.

A founder-approved BC/DR policy is in place, including a founder-unavailability continuity provision.

Automated daily backups via the managed database provider (upgraded specifically to close a prior gap where the free tier had zero automated backups).

Backups run automatically, but a scheduled restore/recovery drill has not yet been performed or documented. Open item.

Hosting and database are both single-region. No multi-region failover is configured. Disclosed as an accepted current limitation, not resolved as fully redundant.

A 24-hour RPO target is documented and met by daily automated backups. A continuous point-in-time-recovery add-on was evaluated and judged unnecessary to meet the stated RPO.

The BC/DR policy names a role (not an individual) explicitly so it remains valid across personnel changes.

All changes to `main` require a pull request, a second-engineer review, and passing CI checks. Branch protection on `main` was verified enabled via the GitHub API.

`enforce_admins` is enabled on `main`'s branch protection (verified via the GitHub API), so required PR review and status checks apply to administrators as well, with no bypass path.

Provider dashboards (hosting, database, secrets manager, source control) retain change history; sensitive account-security actions are additionally written to an internal append-only audit log.

A password-protected staging environment, fed by an intentionally unprotected working branch that merges into `main` only via reviewed PR.

The Configuration Change Control Policy (§3.7) documents an emergency-change path: a founder may self-merge a hotfix directly to main, the change and its rationale must be documented within 24 hours, and it undergoes retrospective review by the other founder within 2 business days.

TLS 1.2+ enforced platform-wide with HSTS.

Two layers: database-level encryption (AES-256, provider-managed) plus an application-level layer (AES-256-GCM) for response content, panel data, and stored credentials.

The application-layer encryption key is held in a dedicated secrets manager outside the database, so a database-only compromise does not expose plaintext response content.

No formal, documented key-rotation cadence currently exists. Open item.

Managed via a dedicated secrets manager (env vars) and password manager (credentials/SSH keys); nothing is committed to source control; database service-role credentials are used server-side only, never exposed to the client.

Domandata is fully cloud-hosted on managed platforms; this domain is entirely inherited from infrastructure providers.

Both the hosting provider and database provider hold SOC 2 Type II certification, which covers physical and environmental controls at their facilities.

No physical servers, offices, or equipment are in scope — all compute and storage is vendor-managed.

A Data Classification & Handling Policy defines general-use data, sensitive data permitted with disclaimer (student/health records, with compliance responsibility on the researcher), and explicitly forbidden data (payment card data).

Self-serve account deletion permanently removes surveys and all associated response data from the production database.

Enforced with Postgres Row-Level Security at the database layer, not solely in application code, so an application bug cannot leak one customer's data to another.

Audit-log retention (minimum one year) is documented, as is survey-version retention behavior, but a single consolidated retention schedule covering all data categories has not yet been formalized as its own policy.

Error monitoring is configured to strip authentication headers, cookies, and request bodies before transmission; raw survey responses never reach analytics tooling.

Domandata does not sign BAAs and does not implement HIPAA safeguards. Stated explicitly in the Terms of Service and on the public Security page; researchers bear compliance responsibility for HIPAA-adjacent data.

Ten policies, approved by both founders and dated, covering the SOC 2 Security Trust Services Criteria.

Maintained in our GRC platform with multiple identified risks, each with a documented status and disposition.

Risk owners have not yet been assigned across all tracked risks. Open item.

All 34 SOC 2 "Security" Trust Services Criteria are mapped to specific policies and controls; the large majority of underlying controls have documented evidence on file.

A Security Lead role is designated (referenced by title, not name, so it remains valid across personnel changes).

A personnel screening addendum was adopted as part of the Code of Ethics policy.

Both founders have read and confirmed the full linked policy set (Code of Ethics, Incident Reporting, Account & Access Management, Malicious Code Protection).

A revocation process is straightforward given the current team size and centralized dashboard-based access model, but it has not yet been exercised against a real departure, so it is unverified in practice.

A Code of Ethics policy is in place and actively maintained.

TOTP-based MFA is fully live (not behind a feature flag) for all customer accounts; workspace Owners can require it for every member of their workspace.

Confirmed enrolled, via dashboard screenshots, for both individuals with access to the four named privileged systems (hosting, database, secrets manager, source control).

Owner / Member / Survey Collaborator (Editor or Viewer) roles, enforced at the database layer via Row-Level Security.

bcrypt; passwords are never retrievable in plaintext by the platform or its operators.

Institutional SSO is not implemented. Institutional access is currently provided through a granted-plan model instead.

API keys are shown once at creation, stored only as a hash thereafter, and can be revoked and regenerated independently at any time.

Exports are available in CSV, JSON, and native statistical formats (SPSS .sav, Stata .dta).

A public REST API (export, codebook, and responses endpoints) is available with published documentation.

All export formats are industry-standard, openly documented data-interchange or statistical-package formats.

Both the compute/hosting provider and the database provider are SOC 2 Type II certified, managed platforms.

The platform is fully serverless/managed; there is no self-administered VM or container infrastructure to secure or patch.

Access is limited to provider-dashboard access for two named individuals, both MFA-enrolled. There is no direct SSH or database access outside server-side API routes using a scoped service credential.

Sign-ins, failed sign-in attempts, MFA enroll/unenroll, password changes, OAuth link/unlink, API key create/delete, exports, and account/workspace changes and deletions are all written to an append-only audit log.

A minimum one-year retention period is documented for the audit log.

A semiannual manual review (January/July) by the Security Lead is documented, organized around specific anomaly patterns (account-takeover clustering, credential lifecycle anomalies, auth anomalies, export volume).

An automated detector fires on clustered sensitive account-security events (two or more of password-changed, MFA-unenrolled, OAuth-linked/unlinked within one hour) with email alerting. This is targeted detection, not full continuous-monitoring or SIEM-grade coverage across all systems.

Authentication headers, cookies, and request bodies are stripped before error reports are sent to the monitoring tool.

Covers detection, escalation, and communication. Given team size, incident communication currently happens directly between the two founders.

Published on the public Security page with a dedicated contact channel, an acknowledgment commitment, and a no-legal-action pledge for good-faith reports.

No reportable security incident has occurred in the trailing 12 months.

The Incident Response Policy establishes an escalation process, but a formal breach-notification timeline and customer-facing template have not yet been separately drafted and exercised.

Audit logging provides an investigative trail for account-security events; a formal cloud-forensics or e-discovery procedure beyond that has not been separately documented.

An internal vendor inventory documents infrastructure (hosting, database), billing, and secrets-management providers.

An annual vendor security review runbook is in place; each vendor's own published security/compliance attestation is checked against Domandata's requirements.

Published at domandata.net/trust/subprocessors, including a commitment to give 30 days' notice before engaging a new sub-processor.

Both the hosting provider and the database provider hold SOC 2 Type II certification.

A dependency audit runs on every pull request and on a weekly schedule in CI; automated vulnerability alerts from the source-control provider are enabled.

Vulnerabilities are remediated promptly on discovery in practice (most recently, all findings resolved via patches and narrowly scoped version overrides rather than risky forced downgrades), but a formal written remediation-SLA commitment is not yet documented.

No third-party penetration test has been performed to date. Open item.

Baseline DDoS and edge protections are inherited from the hosting platform; no independently configured WAF ruleset exists beyond platform defaults.

Framework and dependency updates are pulled in as part of normal development; no known unpatched high-severity vulnerabilities at time of writing.

No centralized MDM/endpoint-management platform is in place; devices are personally owned by the two founders.

Full-disk encryption, screen lock, and automatic updates are expected on both devices in practice but are not yet centrally enforced or formally required in a written device policy.

No endpoint protection software is currently deployed. Disclosed as a known, tracked gap rather than left unaddressed.

No formal lost/stolen device procedure has been documented yet. Open item.