DPA Annex B — technical and organisational measures

Version 2026-10-12-beta.2 · Effective from

The Polish version is legally binding. Translations are provided to help you understand the document.

All documents · Download this version

Service Provider / Operator: Brillnet Piotr Adamski, ul. Henryka Sienkiewicza 73/6, 90-057 Łódź, Polska, NIP 7321779060, REGON 101551294

Service contact: kontakt@wm-admin.pl

Privacy and breach contact: privacy@brillnet-app.com

Website: wm-admin.pl

Version: 2026-10-12-beta.2

This is an informational translation. The Polish version is binding.

1. Architecture and isolation

  1. Each Community has a dedicated private tenant Worker, a D1 database configured for the EU, a private logical and cryptographic R2 scope configured for the EU, and a Durable Object with EU jurisdiction.
  2. The control plane stores identity, membership, billing and routing, but not the Community's business content.
  3. Communication with a tenant uses Service Bindings; public access without tenant context and authorisation is rejected.
  4. Isolation is enforced on the server, not merely by hiding interface elements.

2. Encryption and transmission

  • transmission over HTTPS/TLS;
  • encryption of persistent data provided by the Cloudflare layer;
  • private R2 resources with no public buckets;
  • secrets outside source code, using environment secret mechanisms;
  • signed webhooks and origin verification for integrations.

3. Identity and access

  1. Individual accounts, with no shared accounts.
  2. Sessions in secure cookies with the wm-admin prefix, origin checking and cross-site request forgery (CSRF) protection.
  3. Time-based one-time password multi-factor authentication (TOTP MFA) is mandatory for administration, accounting and the board; available for other roles.
  4. Roles and permissions are checked separately for each Community, following least privilege.
  5. Turnstile protects registration and sign-in.
  6. Support access: based on a request, scope-limited, by default no more than 60 minutes, and audited. Emergency access: no more than 30 minutes, with justification, additional approval and subsequent review.

4. Audit and observability

  1. Sensitive operations are recorded in an append-only audit log with actor, time, tenant, operation type and correlation identifier.
  2. The log should not contain passwords, tokens, complete document content or form fields.
  3. Security logs are retained for at least 12 months and standard operational logs generally for 90 days, unless an incident or legal obligation requires longer.
  4. Production tracing is disabled by default; temporary diagnostics are minimised and do not exceed 1% sampling.

5. Backups and continuity

  1. Daily logical D1 backup to R2 with EU configuration and a 90-day object lock.
  2. D1 Time Travel: a 30-day window.
  3. Targets after formal launch: recovery point objective (RPO) 24 hours, recovery time objective (RTO) 24 hours.
  4. Recovery tests at least quarterly after the production data plane is activated.
  5. Backups are in the same Cloudflare account; the shared-provider risk is explicitly included in the continuity assessment.

6. Secure development lifecycle

  • change review and automated tests;
  • separation of environments and secrets;
  • dependencies scanned and updated according to risk;
  • tenant isolation and authorisation tests as a release requirement;
  • public registration, real data, payments and integrations remain blocked until their release requirements are met;
  • no production data in test environments without controlled anonymisation.

7. Incident management

  1. Reporting channel, classification, containment, evidence preservation, cause analysis, remediation and post-incident review.
  2. Brillnet notifies the Customer without undue delay upon becoming aware of a Customer Data breach. The internal target is a first useful notification within 24 hours; it does not justify waiting when earlier information is available. Information is supplied in stages without awaiting full confirmation of every circumstance.
  3. Procedure exercise at least annually after formal launch.

8. Minimisation and privacy

  1. No external tracking on the landing page.
  2. No tenant data in localStorage, IndexedDB, the Cache API or offline queues.
  3. No generative AI and no model training on Customer Data.
  4. Backup email through Resend is limited to minimal transactional messages, with no tenant documents and with open/click tracking disabled.

9. Personnel and suppliers

People with access are bound by confidentiality, trained and subject to periodic permission reviews. Subprocessors are assessed for security, privacy, location and continuity; changes follow the DPA procedure.

10. Reviews

Measures are reviewed at least annually and after a significant incident, architecture change or change in legal requirements. Changes to technical and organisational measures must not reduce the overall protection level during the Agreement.

Readiness for KSC/NIS2

KSC/NIS2 readiness rests on security measures, supplier controls and incident procedures relevant to WM Administrator. Statutory duties are qualified by entity, sector, service, size and exceptions. Operator duties, customer duties and contractual commitments are separate. On a justified request, relevant service information is supplied with confidentiality safeguards. Using WM Administrator does not itself ensure customer compliance, registration or certification.

> Contact details and domains in this presentation were updated on 2026-09-08. The original document and previous acceptances remain unchanged.