Security

SentaView runs on Google Cloud / Firebase for its data plane and on Vercel for its application layer. Both providers operate ISO 27001-, SOC 2- and ISO 27701-certified infrastructure and are bound by a data-processing agreement.

Data residency

Customer data (authentication, Firestore documents, file storage, serverless-function state) is stored in the europe-west3 region (Frankfurt, Germany). Tenant data never leaves the EEA at rest.

Edge traffic

Static assets and the Next.js application layer are served through Vercel's European edge. Edge nodes are stateless — they hold no customer records.

Tenant isolation

Every document carries a tenant id; every Firestore security rule enforces tenant-scope before row-level checks. There is no shared data between tenants at any layer.

Environment separation

Production, staging and development run in separate Google Cloud projects with independent IAM, credentials and network boundaries. Production data is never copied to non-production environments.

In transit

All traffic between users and SentaView, and between SentaView and its sub-processors, is encrypted with TLS 1.2 or higher. HSTS is enabled on every public domain.

At rest

Firestore and Cloud Storage encrypt all data at rest with AES-256. Encryption keys are managed by Google Cloud KMS and rotated on the provider's standard schedule.

Secrets

Application secrets (API keys, service-account credentials) are stored in Google Secret Manager and are never committed to source control or embedded in build artefacts.

• Customer-facing authentication runs on Firebase Auth with email/password and magic-link sign-in; SSO is available on the Enterprise tier.
• All SentaView staff accounts require multi-factor authentication and are provisioned from a central identity provider. Access is granted by role and revoked within 24 hours of a role change or departure.
• Production access is restricted to a short, named list of engineers. All production access is brokered through audited identity-aware proxies — there is no shared root account.
• Privileged actions (tenant provisioning, phase transitions, data exports, support-driven data access) are logged with actor, timestamp and affected scope. Logs are retained for 12 months.
• Access reviews are conducted quarterly; findings feed back into the IAM configuration.

SentaView has two operating modes, selected per tenant. In Version A (Fully Anonymous), employee pulse submissions never carry an author id at any point — client, transport or storage. In Version B (Opt-in Identity), every submission carries a per-post visibility flag; an author id is attached only when the employee explicitly sets a specific submission to "identified".

• The visibility flag and the absence of an author id on anonymous submissions are enforced by Firestore security rules — not by the client. An adversarial client cannot attach an author id to an anonymous submission.
• Pulse submissions in the anonymous phase are written via a short-lived signed token issued per pulse wave, so an unauthenticated client can submit exactly once per wave without any user identity entering the system.
• The anonymous clarification channel uses an opaque submission-scoped token. A department head can post a follow-up question attached to a specific submission; the original employee's client fetches follow-ups by the set of tokens it holds locally. The server never knows which user authored which submission.
• Aggregated views apply a minimum-group threshold (default: 5) before displaying any breakdown. Below the threshold, the UI shows "not enough signal yet" rather than partial data.

SentaView relies on a small number of sub-processors to deliver the service. All are bound by a data-processing agreement. Any addition of a sub-processor is communicated to customers at least 30 days before it takes effect, with a right to object on legitimate grounds.

Google Cloud / Firebase — Google Ireland Limited

Primary data plane: authentication, Firestore, Cloud Functions, Cloud Storage. Region: europe-west3 (Frankfurt). Transfer mechanism for any indirect US transfer: EU-US Data Privacy Framework + Standard Contractual Clauses.

Vercel Inc.

Hosting and edge delivery for the Next.js application. EU edge regions. Transfer mechanism: EU-US Data Privacy Framework + Standard Contractual Clauses.

[TRANSACTIONAL EMAIL PROVIDER, e.g. Postmark / SendGrid]

Transactional email: magic-link sign-in, pulse notifications, account emails. EU region. Transfer mechanism where applicable: Standard Contractual Clauses.

• Firestore is backed up daily with managed exports retained for 30 days in a separate Google Cloud project. Backups are encrypted at rest with the same AES-256 standard as the primary data store.
• Our target recovery point objective (RPO) is 24 hours and our target recovery time objective (RTO) is 8 hours for the full service.
• Backup restores are tested at least twice per year. A restore test failure triggers a root-cause review before the next deployment window closes.

• Dependencies are scanned on every pull request (GitHub Dependabot + Socket) and on a daily schedule for the main branch. Critical advisories are remediated within 7 days; high within 30.
• Static analysis (ESLint with security plugins + TypeScript strict mode) runs on every pull request and blocks merge on findings.
• Container and infrastructure configuration is reviewed against CIS benchmarks before each release.
• An independent penetration test of the application is performed at least annually; findings are tracked to closure and a remediation summary is made available to customers on request under NDA.

SentaView maintains a written incident-response plan covering detection, containment, eradication, recovery and post-incident review. The plan is reviewed at least annually and after any material change to the service.

• Security events are detected through centralised logging, Firebase / Google Cloud audit logs and Firestore rule denials.
• In the event of a personal-data breach that is likely to result in a risk to the rights and freedoms of affected individuals, we notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, in line with Art. 33 GDPR.
• Affected customers are notified as soon as the scope is established, in parallel with — not after — authority notification. The notification includes the nature of the incident, the categories and approximate volume of data affected, the measures taken, and a named point of contact.
• Every material incident is followed by a written root-cause analysis and a list of preventative measures. The RCA is shared with affected customers on request.

• All SentaView personnel sign confidentiality undertakings before being granted access to any production system.
• Security and data-protection training is delivered at onboarding and refreshed at least annually.
• Background checks are performed on personnel with access to production data where permitted by local law.
• Sub-contractors handling customer data are bound by equivalent obligations through written data-processing agreements.

• Processing is aligned with the EU General Data Protection Regulation (GDPR) and, for customers in Germany, the Bundesdatenschutzgesetz (BDSG).
• We align our controls with the ISO/IEC 27001 framework and intend to pursue formal certification once our scale warrants it.
• Our primary infrastructure sub-processors (Google Cloud, Vercel) hold current ISO 27001, SOC 2 Type II and ISO 27701 attestations; their reports are available under NDA through the respective provider's trust portal.

SentaView offers a standard data-processing agreement (DPA) that incorporates the Standard Contractual Clauses where applicable. The DPA includes an up-to-date list of sub-processors, a description of the technical and organisational measures summarised on this page, and a contractual commitment to the 72-hour breach-notification process described above.

To request the DPA, or to raise a security or compliance question not covered on this page, contact emil.zawadzki@sentaview.de.