Data Processing Agreement

This Data Processing Agreement ("DPA") governs the processing of personal data by Capme Digital GmbH, c/o TechHub.K67, Kasernenstraße 67, 40213 Düsseldorf, Germany ("Processor", "Capme") on behalf of the customer identified in Annex I ("Controller", "Customer") in the course of providing the Capme service under the Terms of Service at https://capme.app/terms (the "Agreement"). These clauses follow the standard contractual clauses adopted by the European Commission under Article 28(7) of Regulation (EU) 2016/679 (Implementing Decision (EU) 2021/915), with the options set out below, and are intended to fulfil the requirements of Article 28(3) and (4) GDPR. They apply to every workspace of the Customer and to every plan. The DPA is accepted when a trial or a plan is started for the Customer's workspace, by the person acting for the Customer ticking the box that references it, and the acceptance is recorded with the version accepted, the time, the IP address and the browser. On request Capme provides the same text as a PDF countersigned by both parties.

The parties undertake not to modify the clauses of this DPA except to add information to the annexes or to update them. This does not prevent the parties from including these clauses in a broader contract or adding other clauses, provided they do not contradict this DPA or detract from the fundamental rights or freedoms of data subjects. Terms defined in the GDPR have the meaning given there. This DPA is to be read and interpreted in the light of the GDPR and not in a way that conflicts with its rights and obligations. In the event of a contradiction between this DPA and any other agreement between the parties, including the Terms of Service, this DPA prevails with regard to the processing of personal data.

The details of the processing, in particular the categories of personal data and the purposes for which the personal data is processed on behalf of the Controller, are specified in Annex II. Where the Customer uses its own storage bucket, recordings are transmitted from the members' browsers directly to that bucket and Capme stores only the metadata described in Annex II; the bucket's provider is engaged by the Customer and is not a subprocessor of Capme.

4.1 Instructions. The Processor processes personal data only on documented instructions from the Controller, unless required to do so by Union or Member State law to which the Processor is subject; in that case the Processor informs the Controller of that legal requirement before processing, unless the law prohibits this on important grounds of public interest. The Agreement, this DPA and the Controller's use of the Service's settings and functions constitute the Controller's instructions; further instructions may be given in writing to security@capme.app. The Processor immediately informs the Controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection law. 4.2 Purpose limitation. The Processor processes the personal data only for the specific purposes set out in Annex II, unless it receives further instructions from the Controller. 4.3 Duration. Processing takes place for the duration of the Agreement and until deletion under clause 8. 4.4 Security of processing. The Processor implements at least the technical and organisational measures specified in Annex III to ensure the security of the personal data, including protection against a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. In assessing the appropriate level of security the parties have taken into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing and the risks for the data subjects. The Processor grants access to the personal data to members of its personnel only to the extent strictly necessary for performing the Agreement, and ensures that they have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. 4.5 Sensitive data. The Service is not intended for special categories of personal data (Article 9 GDPR). A recording may nevertheless contain such data incidentally, for example because of what a screen shows or what a person says. The Controller decides whether to record it; the Processor applies the measures of Annex III to all recordings alike, including access restricted to the workspace, signed playback links, encryption in transit and at rest, and deletion on the Controller's schedule. 4.6 Documentation and compliance. The parties are able to demonstrate compliance with this DPA. The Processor deals promptly and adequately with enquiries from the Controller about the processing, makes available all information necessary to demonstrate compliance with the obligations under this DPA and Article 28 GDPR, and allows for and contributes to audits of the processing activities covered by this DPA at reasonable intervals or if there are indications of non-compliance. The Controller may decide to conduct the audit itself or mandate an independent auditor bound by confidentiality; audits are announced in writing at least thirty days in advance, take place during business hours and without disproportionate disruption, and may be answered first by the documentation the Processor maintains (this DPA, the Trust Center at https://capme.app/trustcenter, and the audit log the Controller can export). The parties make the information referred to in this clause, including the results of audits, available to the competent supervisory authority on request. 4.7 Use of subprocessors. The Processor has the Controller's general authorisation to engage subprocessors from the list in Annex IV. The Processor specifically informs the Controller in writing, by email to the workspace owner's address, of any intended changes to that list through the addition or replacement of subprocessors at least thirty days in advance, giving the Controller sufficient time to object before the subprocessor is engaged. The Controller may object on reasonable data protection grounds; if the parties cannot resolve the objection, the Controller may terminate the affected service with immediate effect and receives a pro-rata refund of prepaid fees for the unused period. Where the Processor engages a subprocessor, it does so by way of a contract that imposes on the subprocessor, in substance, the same data protection obligations as those imposed on the Processor under this DPA, and it ensures that the subprocessor complies with those obligations. At the Controller's request the Processor provides a copy of such a subprocessor agreement and any subsequent amendments, with commercial information redacted. The Processor remains fully responsible to the Controller for the performance of the subprocessor's obligations. 4.8 International transfers. Any transfer of personal data to a third country or an international organisation by the Processor takes place only on documented instructions from the Controller or in order to fulfil a specific requirement under Union or Member State law to which the Processor is subject, and in compliance with Chapter V GDPR. The Controller agrees that where the Processor engages a subprocessor under clause 4.7 for processing that involves a transfer to a third country, the Processor and the subprocessor may ensure compliance with Chapter V by using the standard contractual clauses adopted by the Commission under Article 46(2) GDPR, or an adequacy decision including the EU-US Data Privacy Framework where the subprocessor is certified. Annex IV states the mechanism used for each subprocessor.

The Processor promptly notifies the Controller of any request it receives from a data subject and does not respond to it itself unless authorised by the Controller. Taking into account the nature of the processing, the Processor assists the Controller in fulfilling its obligation to respond to requests for exercising data subjects' rights, by the functions of the Service (members and admins can view, correct and delete the data the Service holds about a person; admins can remove members and, on Business and Enterprise, export the audit log) and, beyond that, on request. The Processor further assists the Controller, taking into account the nature of the processing and the information available to it, in ensuring compliance with the obligations under Articles 32 to 36 GDPR: the security of processing (Annex III), the notification of personal data breaches to the supervisory authority and to data subjects (clause 6), data protection impact assessments and prior consultation. The Processor provides the information required for the Controller's records of processing activities on request; the description in Annex II and the Trust Center are written for that purpose.

In the event of a personal data breach concerning data processed by the Processor under this DPA, the Processor notifies the Controller without undue delay and in any case within 48 hours after having become aware of it, by email to the workspace owner's address and to any further address the Controller has named. The notification contains at least: a description of the nature of the breach, including where possible the categories and approximate number of data subjects and records concerned; the contact point for further information; the likely consequences; and the measures taken or proposed to address the breach and mitigate its effects. Where all information cannot be provided at once, it is provided in phases without undue further delay. The Processor assists the Controller in complying with the Controller's own notification obligations under Articles 33 and 34 GDPR, in particular by providing the information above and by preserving the records needed to reconstruct the incident, including the audit log. A breach at a subprocessor is treated as a breach at the Processor for the purposes of this clause.

Without prejudice to the GDPR, if the Processor is in breach of its obligations under this DPA, the Controller may instruct the Processor to suspend the processing until the breach is remedied or the Agreement is terminated. The Controller may terminate the Agreement insofar as it concerns the processing under this DPA if the Processor is in substantial or persistent breach of this DPA, if the Processor fails to comply with a binding decision of a competent court or supervisory authority regarding its obligations under this DPA or the GDPR, or if the processing has been suspended for more than one month. The Processor may terminate the Agreement if the Controller insists on an instruction that the Processor has flagged as infringing applicable law and the Controller does not withdraw it within thirty days.

The Controller may retrieve its personal data at any time during the Agreement: recordings as MP4 files, which the Processor exports on request free of charge; the audit log as CSV, which admins on Business and Enterprise export themselves and the Processor provides on request on other plans; and the remaining metadata as JSON or CSV on request. After the end of the Agreement the Controller has 30 days to retrieve the data. The Processor deletes it on the Controller's instruction (workspace deletion, which the Controller triggers itself and which takes effect after a grace period of fourteen days) or, absent an instruction, when those 30 days have passed. Deletion covers every host the Processor uses, including its video provider, and the access key to the Controller's own bucket. Recordings in the Controller's own bucket are not deleted by a workspace deletion: they remain the Controller's files under the bucket's own rules. The Processor removes a recording from that bucket when a member deletes it in the Service, and on no other occasion. The Processor confirms deletion in writing on request. Data the Processor must retain under Union or Member State law, in particular invoices and accounting records, is kept for the statutory period and then deleted. The workspace's audit log survives its deletion unchanged, and each entry is deleted 365 days after it was written.

Liability between the parties for damage caused by processing that infringes the GDPR is governed by Article 82 GDPR: each party is liable for the damage caused by its own infringement. Administrative fines imposed on one party are borne by that party. The limitation of liability in the Terms of Service applies to claims between the parties under this DPA, except where it would conflict with Article 82 GDPR or with mandatory law. This DPA is governed by the law of the Federal Republic of Germany. The place of jurisdiction is Düsseldorf. It exists in German and English; both versions are binding, and where they differ the German version prevails. The annexes form part of this DPA: Annex I (parties), Annex II (description of the processing), Annex III (technical and organisational measures) and Annex IV (subprocessors). Changes to Annex III that do not lower the level of protection, and changes to Annex IV under clause 4.7, do not require a new acceptance of this DPA.

Controller: the customer that created the workspace, identified by the workspace name and the accepting person's details recorded at acceptance and by the registered name, legal form, billing address and tax identifier the Customer gives before a paid plan begins. The workspace owner is the Controller's contact for this DPA unless another contact is named in the settings. Processor: Capme Digital GmbH, c/o TechHub.K67, Kasernenstraße 67, 40213 Düsseldorf, Germany. Contact for data protection: security@capme.app. Acceptance: recorded per workspace with the DPA version, the date and time, the accepting person's email address, IP address and browser. The record is available to the Controller on request and is retained for the life of the workspace.

Categories of data subjects - Members of the Controller's workspace: employees, contractors and other persons the Controller admits. - Speakers: members who record a topic. - Viewers: persons the Controller places on a meeting's audience, who may be members or external persons. - Persons who appear in a recording (in vision, in voice or on a shared screen) without being members. - Persons who open an unlisted link the Controller has shared. Categories of personal data - Recordings: video image, voice and screen content of the people recorded, together with title, length, size, poster frame and status. This is the principal category. - Identity and profile: email address, display name, job title, role, language; where the Controller has connected its identity provider, the sign-in assertion it sends (email address, and name and job title if sent) and the sign-in method recorded per session. - Meetings: titles, descriptions, agendas with the speaker of each topic, deadlines, audience lists, publication state. - Engagement: watch progress per person and topic (furthest point, time), applause, in-app notifications and their read state, reminders sent. - Recording statistics: for each take, how it was recorded (capture mode, quality, format, length, size, which recorder features were used), never its content. - Workspace administration: settings, branding files, claimed domains, orders of speakers, storage configuration (with the bucket credential encrypted), the identity provider connection with its enforcement scope and per-address exceptions, public links and their view counts. - Audit log: who did what, when, from which IP address and browser. - Legal-acceptance records: which version of the Terms, the Privacy Notice and this DPA was accepted, when, from where. Special categories of data (Article 9 GDPR): not intended. A recording may contain them incidentally; see clause 4.5. Nature and purpose of the processing: hosting, storing, transcoding, streaming and deleting recordings; running asynchronous meetings (inviting speakers, collecting recordings, publishing playlists, reminding, recording watch progress); signing members in by emailed code or, where the Controller has connected its identity provider, by single sign-on over SAML 2.0, with no password and no second factor held by the Processor; administering the workspace (members, roles, speakers, access, branding, storage, retention); sending the transactional emails these functions require; and keeping the audit log. No other purpose: the Processor does not analyse content, does not train models, and does not use the data for its own purposes beyond aggregated, anonymous usage statistics. The one exception is the recording statistics above: the Processor also uses them as a controller in its own right, to improve the recorder, as its Privacy Notice describes. They never contain what was recorded, and when an account, a workspace or a recording is deleted, they keep no link to it. Duration: the term of the Agreement, the retention windows the Controller sets, and the deletion periods in clause 8. Subprocessing: the subprocessors in Annex IV process the categories above to the extent stated there. Where the Controller uses its own storage bucket, recordings and poster frames are stored only there.

The measures under Article 32 GDPR that Capme maintains for the processing described in Annex II. Last reviewed 1 October 2026. The same catalogue is published on the Trust Center. C.1 Where data lives The service has three postures for a recording, and the customer chooses between them by plan and setting. - In the browser. The free recorder writes every take to the browser's private storage on the user's device. No recording leaves the device unless the user uploads it; the recorder reports how a take was recorded (its settings, length and size), never its content. This is the only posture on the Free plan. - EU hosting. A recording made for a meeting or for the library uploads from the browser directly to Bunny Stream's EU storage region in Germany as soon as the take ends, where it is stored and transcoded. Capme's servers hold the metadata and pass a recording's poster image through when a page shows it; they never hold the video. - The customer's own bucket. On Business and Enterprise, and during a Business trial, a workspace can point recordings at an S3-compatible bucket it operates. The video goes from the browser to the bucket and plays from there without passing through Capme. The poster image is sent to Capme's server, which writes it to the bucket and passes it through when a page shows it. The application runs on Hetzner in Germany; the database, authentication and branding files run on Capme's own Supabase instance at id.capme.app, operated by Elestio Limited (Ireland) on netcup GmbH infrastructure in the Nuremberg data centre, Germany. Capme itself stores no customer data outside the European Union; subprocessors that transfer data outside it are named with their transfer basis in Annex IV. C.2 Encryption in transit Every connection between a browser and Capme, between Capme and its subprocessors, and between a browser and a video host uses TLS 1.2 or higher, TLS 1.3 preferred. Uploads to the video host and to a customer bucket are HTTPS from the browser; a bucket endpoint that is not HTTPS is refused. The CDN in front of the site terminates TLS and adds a shared origin secret to each request, which the application checks. HTTP Strict Transport Security is set on every response. C.3 Encryption at rest Recordings on EU hosting are stored encrypted at rest by Bunny. The database lives on Capme's own instance in Nuremberg (C.1). Its port is closed to the internet, and its programming interfaces answer only to a key that never leaves Capme's servers, except for the sign-in links, the single sign-on endpoints and the branding files described next. Branding files (logos and backgrounds) sit in a publicly readable storage bucket on the same instance, because every recording and public page shows them. Each file has a random name, and the bucket cannot be listed, so a file can be opened only by someone who was shown its address. Recordings in a customer bucket are encrypted by that provider under the customer's own configuration. The secret access key a workspace gives Capme for its bucket is encrypted with AES-256-GCM under a key that exists only on Capme's servers, is never shown again after entry and is never written to a log; the endpoint, bucket name and key ID are stored as ordinary settings. Recordings in the browser are protected by the device's own storage encryption (for example FileVault or BitLocker) where the user has enabled it. C.4 Authentication - Sign-in is by email address and a six-digit one-time code or a magic link sent to that address. There are no passwords to phish, reuse or leak. - Requests for a code are limited to 5 per 15 minutes per address and 20 per IP address; code attempts to 6 per 15 minutes per address and 30 per IP address. Sign-ins and failed attempts are logged with the address, IP address and browser (C.11). - Sessions are HttpOnly, SameSite=Lax cookies issued by Capme's own sign-in service (Supabase Auth at id.capme.app), rotated automatically and cleared on sign-out. A session ends after 30 days at the latest, or after 14 days without use. - Invitations to record a topic carry an HMAC-signed token valid for seven to fourteen days, compared in constant time, and re-checked against the current assignment and an active membership when it is opened. - Single sign-on over SAML 2.0 is available to Business and Enterprise and during a Business trial: one connection per workspace, covering its verified email domains, configured by the workspace owner and tested with a real sign-in before it can be enforced. A session from the identity provider counts only for an address at those domains, and only inside that workspace. Once single sign-on is enforced, a new emailed code is refused for the workspace's own people at those domains and for addresses there that belong to no workspace yet, including at the free recorder's save gate; sessions already open stay open until they end. Exceptions are granted per address with a reason and an expiry, and there is no break-glass account. Accounts are created on first sign-in; SCIM and OIDC are not offered. - Capme has no second factor of its own. Where a workspace enforces single sign-on, multi-factor authentication is the customer's identity provider's policy and is enforced there; Capme records the sign-in method and does not verify the factor. C.5 Access control in the workspace - Three roles: owner, admin, member. One owner per workspace, enforced by the database. Owners manage admins, admins manage members. Storage settings and workspace deletion are the owner's alone. - People join when an admin adds them. An admin can also let members add colleagues at the workspace's verified domains as viewers, and on Business and Enterprise let anyone who signs in with an address at those domains join on their own. A domain is verified by an admin signing in with an address at it; public mailbox domains cannot be claimed, and a domain can be claimed by one workspace only. - A meeting is visible to its organiser, its speakers, its audience and the workspace's admins and owner. Somebody not on the list can only request access from the organiser. - A recording can be deleted by its owner or a workspace admin. Publishing a meeting outside the workspace is possible only by its organiser, only after ticking a box that every speaker agreed, and only while a workspace admin has allowed public links at all; a speaker can publish a single recording of their own under the same switch. Any speaker can withdraw their recordings from public links from their own profile. - Every privileged action is written to the workspace's audit log (C.11). C.6 Tenant isolation and internal access - Every table of the meeting product has row-level security enabled with no policies and every grant to anonymous and authenticated roles revoked. Only the server, with a service credential held in environment variables, reaches the data, and only through server actions and API routes that check the caller's membership and role on every request. Tables left from the previous version of the product are still on the instance and are being removed. - Recordings in a customer bucket are namespaced by workspace identifier. No automatic job deletes a recording in a customer bucket: a recording's files are removed only when a member deletes that recording. A nightly job aborts upload sessions that were started under the workspace's prefix and never finished. - Access to production systems (hosting console, database console, video host, DNS) is limited to the people who operate the service and requires multi-factor authentication. The database console asks first for a passkey on Capme's own identity service and then for a password. SSH logins to the servers use keys, not passwords. Administrative actions on those systems are logged by the providers. - Capme's staff do not open customer recordings except on the customer's request for support, and every such access is documented. C.7 Cookies and client storage The site sets no marketing or tracking cookies and shows no consent banner because none is required: the cookies in use are the sign-in session, a session flag for a seen legal notice, a one-hour invitation cookie, a fourteen-day Trust Center access cookie, and preferences (language, theme, collapsed rail). The complete list with lifetimes is section 3 of the Privacy Notice. Session and access cookies are HttpOnly and SameSite=Lax. Recorder settings, drafts and the point where playback resumes stay in the browser; the furthest point a person reached in a topic is stored as watch progress (C.14), and the recorder reports its settings, never its content, to the analytics (C.9). C.8 Network, CDN and application hardening - All traffic to capme.app passes through bunny.net's CDN, which absorbs volumetric attacks and keeps request data in memory for seconds only. The CDN adds a shared secret to each request, which the application checks, and passes the client's address in a header the application reads. - A Content Security Policy is generated per request with a nonce and strict-dynamic, so only scripts the page itself started can run; media and connections are limited to the named video hosts and the customer bucket hosts on an allowlist that is code, not configuration. Framing is denied everywhere except on the embed route for public links. - Playback of hosted video uses addresses signed per file, which the watch page renews on its own while someone watches; a customer who serves its bucket publicly has its own addresses used instead. Upload credentials expire after 15 minutes (customer bucket) or 6 hours (EU hosting). - Webhooks from the video host and the payment provider are verified with a shared secret or a signature; internal jobs require a secret compared in constant time. - Input at every boundary is validated against a schema; fields the schema does not know are dropped. C.9 Analytics and telemetry Product analytics run on OpenPanel, self-hosted on Capme's own server in the EU. No cookie, no persistent identifier, no cross-site tracking; the IP address is used to derive a country and is not stored. Events carry page views, including pages of the meeting product, and interface actions such as opening a meeting or watching a chapter, and, from the recorder, the settings of a take, never its content. No event carries a user identifier. Users can opt out with a browser storage key; automated browsers are excluded. Error tracking is not enabled; nothing is sent to an error-reporting service. C.10 Availability and backups The application is deployed on Hetzner through Coolify from a container image that is built only when the type checks, the lint rules and the unit tests pass. The database runs on Capme's own instance, whose operator Elestio takes snapshots of the whole virtual machine. Capme does not currently promise a logical database backup schedule or point-in-time recovery. Recordings on EU hosting are stored by Bunny in one storage region, and a deleted recording cannot be restored from it; recordings in a customer bucket are the customer's to back up. A workspace can ask Capme at any time to export its recordings as MP4 files, free of charge. The current status and uptime are published at https://status.capme.app. Capme does not run its own data centre. C.11 Logging and the audit log Every workspace has an audit log of who did what and when, with the actor's address and, where a request caused the entry, its IP address and browser: members added, removed and re-added, role changes and ownership transfers, settings, branding and storage changes (never the value of a secret), retention and keep decisions, deletions, public links created and revoked with the organiser's attestation, exports, plan changes and legal acceptances. Sign-ins, failed codes and sign-outs are logged the same way, as a record of the person rather than of a workspace, so they are not part of a workspace's log or export; Capme uses them to reconstruct a security incident. Nothing in the product updates an entry; the log survives the deletion of its workspace and is aged out by a nightly job after 365 days. Business and Enterprise can export it as CSV (the most recent 5,000 entries, up to five exports an hour), and the export is itself logged; on other plans Capme provides the export on request. C.12 Security programme Certifications. Capme holds no certification of its own (no SOC 2, no ISO 27001). Its hosts do: Hetzner ISO 27001; netcup ISO 27001 and ISO 27701. Assessments. No independent penetration test or security assessment has been run yet, of the product or against production. Vulnerability management. Dependencies are monitored automatically; critical security patches are applied within seven days of disclosure. The container image is built only when the type checks, the lint rules and the unit tests pass, and the release script checks the environment manifest. Changes are made by a single developer; there is no second reviewer. Responsible disclosure. security@capme.app, published in machine-readable form at https://capme.app/.well-known/security.txt. People. Capme Digital GmbH is operated by its managing director; everyone with production access is bound to confidentiality. C.13 Data minimisation Recording needs no account. An account needs an email address and nothing else; display name and job title are optional. Public pages show a speaker's display name, or the part of their address before the @ if none is set, and never the address. Analytics carry no user identifier. Emails carry what the recipient needs to act. The recorder's settings, drafts and custom images stay on the device. A save count has not been kept since 21 September 2026. The audit log never records the value of a secret, and for storage settings only the names of the fields that changed. C.14 Purpose limitation Customer data is processed to provide the service to the workspace and for nothing else. Capme does not analyse the content of recordings, does not transcribe or summarise them, does not train models on them and does not use them for its own purposes. Aggregate, anonymous usage statistics are the only secondary use. Watch progress is shown to the meeting's organiser and the workspace's admins as the product's own feature; Capme builds no scores or performance ratings from it. A workspace admin can restrict it to totals, in which case no one's individual progress, including whether they opened a meeting, leaves the server. The admin overview also names up to ten people who still owe recordings, with how many and since when; that list does not depend on the totals setting. Where an employer's law requires it (in Germany the works council's co-determination under §87(1)(6) BetrVG), the customer decides whether and how to deploy those features; the Trust Center documents what is measured and who sees it. C.15 Retention and deletion - Hosted recordings: purged by a nightly job after the workspace's retention window (365 days; on Solo, Business and Enterprise the workspace can set anything from 1 to 365 days). A recording's deletion date is set when it is made and again when it is added to a meeting, so a changed window applies from then on. If a night's purge would take an unusually large share of one workspace's recordings, it is held for a person to check. A recording or meeting can be kept beyond the window; deleting always wins over keeping. Recordings in a customer bucket have no window of ours; the bucket's own lifecycle rules apply. - Deleting a recording removes it from the host without delay and detaches it from every meeting. - Deleting a workspace: 14 days of grace during which nothing is destroyed and the request can be withdrawn; then the recordings we host, the branding files, every row except the audit log (C.11) including the bucket access key, and the logins of members who belong to no other workspace; recordings in a customer bucket stay there. Branding files no row points to are swept nightly; in a customer bucket, files no recording points to are only reported. - A workspace whose paid plan ended: read-only for 30 days, the owner and admins warned by email 7 days before the end, then deleted as above without the grace period. An expired trial is not deleted this way. - Audit log: 365 days. Server logs: a short period, for security and fault finding. Support mail: at most three years. Trust Center requests: two years. Invoices: ten years. - Data subject requests are worked by hand from a runbook that lists every table a person can appear in, within one month. C.16 Incident response 1. Anyone can report an incident or a vulnerability to security@capme.app. 2. Capme contains the incident, assesses which workspaces and data are affected using the audit log and the providers' logs, and preserves the evidence. 3. Affected customers are notified without undue delay and within 48 hours of Capme becoming aware, at the workspace owner's address, with the information Article 33(3) GDPR lists, so that the customer can meet its own 72-hour obligation; supervisory authorities and data subjects are notified where Capme itself is the controller. 4. A written post-incident review records the cause, the fix and what changes. Incidents at a subprocessor are handled the same way. The list of workspaces to notify is derived from the database. The procedure has not yet been rehearsed; a rehearsal is due before the first paying customer.

The following subprocessors are authorised under clause 4.7 to process personal data for the purposes stated. Last change: 30 September 2026. Capme notifies the workspace owner by email at least thirty days before adding or replacing a subprocessor.