This Data Processing Addendum (“DPA”) forms part of the Terms of Service (the “Terms”) between Optiarms Inc., doing business as D.A.R.Y.L. Labs (“Daryl Labs,” “we” or “us”) and the organization that has agreed to the Terms (“Customer” or “you”). It applies whenever we process Customer Personal Data in providing Daryl Shield and its plans (the “Service”).
1. How this DPA applies
This DPA is incorporated into the Terms automatically for every customer, from the moment the Customer first connects a system to the Service or otherwise causes us to process Customer Personal Data, and remains in effect for as long as we process Customer Personal Data. No separate signature is needed. If a Customer needs a countersigned copy for its records, it may request one at hello@getdaryl.com; the countersigned copy will be in the same terms.
The Service is in early access. Some features this DPA describes, including the policy engine and its proofs, traffic replay, canary deployments, signed receipts and the transparency log, may not yet be available to the Customer. Where this DPA describes how a feature handles data, it describes the processing that takes place when that feature is in use.
2. Definitions
In this DPA:
- “Data Protection Laws” means all laws that apply to the processing of Customer Personal Data under the Terms, including, where applicable, the California Consumer Privacy Act as amended by the California Privacy Rights Act and its regulations (“CCPA”), other US state consumer privacy laws, Regulation (EU) 2016/679 (“GDPR”), the GDPR as it forms part of the law of the United Kingdom together with the Data Protection Act 2018 (“UK GDPR”), and the Swiss Federal Act on Data Protection.
- “Customer Personal Data” means personal data contained in Customer Data that we process on the Customer’s behalf in providing the Service, as described in Annex I.
- “Customer Data” means data the Service reads from, or receives about, systems the Customer connects, including schema metadata, policy text, grants, function definitions, request shapes and estimated row counts.
- “Controller,” “Processor,” “Data Subject,” “Personal Data,” “Processing” and “Supervisory Authority” have the meanings given in the GDPR, and “Business,” “Service Provider,” “Sell” and “Share” have the meanings given in the CCPA. Equivalent terms in other Data Protection Laws are read accordingly.
- “Subprocessor” means a third party we engage that processes Customer Personal Data on our behalf.
- “Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data while it is processed by us or our Subprocessors.
- “Standard Contractual Clauses” or “SCCs” means the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914, and the “UK Addendum” means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner.
- “Instructions” means the Customer’s documented instructions for processing, as described in section 4.
Other capitalized terms have the meaning given in the Terms.
3. Roles and scope
3.1 Roles
For Customer Personal Data, the Customer is the Controller (or, where the Customer acts for its own client, a Processor acting on that client’s instructions) and Daryl Labs is the Processor (or Subprocessor). Under the CCPA, the Customer is the Business and Daryl Labs is the Service Provider.
Daryl Labs is an independent Controller for account, billing, website and Check data, which our Privacy Policy governs, and for de-identified aggregate data permitted by section 4.4. This DPA does not apply to that data.
3.2 Agencies
Where the Customer is an agency or other service provider operating an app for its own client, the Customer warrants that its client has authorized it to engage Daryl Labs as a Subprocessor on these terms, and the Customer remains our sole point of contact. The Customer is responsible for passing on any notices this DPA requires to its client.
3.3 Customer responsibilities
The Customer is responsible for the lawfulness of the processing it instructs, for having a lawful basis and giving any notices needed for us to process Customer Personal Data, and for the accuracy of Customer Data. The Customer will not put special categories of personal data into schema names, comments, policy text or function definitions that the Service reads, and acknowledges that the Service is designed to work from structure rather than row contents.
4. Processing on documented instructions
4.1 What counts as an instruction
We process Customer Personal Data only on the Customer’s documented instructions. The Customer’s complete Instructions at the date of this DPA are:
- to provide the Service as described in the Terms, the documentation and the plan the Customer has chosen;
- the autonomy settings the Customer chooses for each app (Suggest, Act with undo or Autopilot), together with the rules the Service applies to them;
- each approval, rejection, snooze, accepted risk, undo or other decision a person authorized by the Customer makes in the dashboard, by pull request, in Slack or through our API;
- the connections the Customer makes, and the scopes it grants, to Supabase, GitHub, Slack or its deploy platform;
- the Customer’s other settings, such as replay mode, canary window and whether public receipts are on; and
- any other reasonable written instruction the Customer gives that is consistent with the Terms.
Autonomy settings and approvals are documented instructions: when Shield applies a proven narrowing under an autonomy setting the Customer chose, or applies a fix a Customer user approved, it is acting on the Customer’s instructions. Every such instruction is recorded in an append-only audit log with who gave it and when. Restoring the exact prior state of a policy after a canary breach, which Shield does on its own, is part of the processing the Customer instructs by enabling the Service.
4.2 Unlawful instructions
We will tell the Customer promptly if, in our opinion, an instruction infringes Data Protection Laws, and may suspend the affected processing until the Customer confirms or changes it. We may also process Customer Personal Data where required by US law, in which case we will tell the Customer of that requirement first unless the law forbids it.
4.3 What we will not do
- We will not copy table rows or read row contents from a Customer’s database.
- We will not use Customer Personal Data to train any AI model, ours or a third party’s.
- We will not sell or share Customer Personal Data, or use it for advertising.
- We will not combine Customer Personal Data with personal data we receive from or on behalf of other persons, except as the CCPA and other Data Protection Laws permit a Service Provider to do.
4.4 De-identified data
We may derive de-identified, aggregate information from Customer Data, such as how often a kind of misconfiguration occurs or how often fixes are rolled back, and use it to improve and describe the Service. We publish or share a pattern or fix template only when it is observed in at least 20 independent organizations, and it never contains row data, identifying schema names or Personal Data. We will maintain such information in de-identified form, take reasonable measures to prevent its re-identification, and contractually prohibit any recipient from re-identifying it.
5. Confidentiality of personnel
We ensure that everyone authorized to process Customer Personal Data, whether employees or contractors, is bound by a written duty of confidentiality or a statutory obligation of confidentiality, has access only as their role requires, and is instructed in the measures in Annex II.
6. Security
We implement and maintain the technical and organizational measures in Annex II, which are designed to protect Customer Personal Data against Personal Data Breaches and to provide a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing. We may update those measures as technology and risks change, provided the update does not materially lower the overall level of protection.
7. Subprocessors
7.1 General authorization
The Customer gives us general authorization to engage Subprocessors. Our current Subprocessors are listed by role, with their purpose, the data they process and their location, on our Subprocessors page (Annex III). The Customer may request the names of our Subprocessors under confidentiality by writing to hello@getdaryl.com.
7.2 Our obligations
We enter into a written agreement with each Subprocessor that imposes data protection obligations no less protective of Customer Personal Data than those in this DPA, to the extent applicable to the services it provides. We remain liable to the Customer for each Subprocessor’s performance of those obligations.
7.3 Notice of changes and right to object
We will give at least 30 days’ notice before a new Subprocessor begins processing Customer Personal Data, by updating the Subprocessors page and emailing the Customer’s account owners. Within that period, the Customer may object on reasonable grounds relating to data protection by writing to hello@getdaryl.com. We will then work with the Customer in good faith to find a reasonable alternative, such as not using the Subprocessor for the Customer’s data or changing the configuration of the Service. If we cannot do so within 30 days of the objection, the Customer may terminate the affected part of the Service by written notice and receive a pro-rata refund of prepaid fees for the terminated part. In an emergency, such as replacing a Subprocessor that has failed or become a security risk, we may give shorter notice, and will give it as soon as we reasonably can; the Customer’s right to object still applies.
8. Assistance
8.1 Data subject requests
Taking into account the nature of the processing, we will assist the Customer by appropriate technical and organizational measures, insofar as possible, in responding to requests from Data Subjects to exercise their rights. If we receive such a request directly and can identify the Customer, we will forward it to the Customer without undue delay and will not respond to it ourselves, except to tell the Data Subject that we have passed it on, unless the Customer authorizes us to. Because the Service does not store row contents or end-user identifiers in clear form (request shapes carry keyed hashes of end-user IDs), much Customer Personal Data cannot be linked to a named individual by us.
8.2 Impact assessments and consultation
We will provide reasonable information and assistance to help the Customer carry out data protection impact assessments and any prior consultation with a Supervisory Authority that Data Protection Laws require, to the extent the Customer does not otherwise have access to the relevant information. We may charge a reasonable fee for assistance beyond providing our standard documentation.
8.3 Security obligations
We will assist the Customer in meeting its obligations relating to security, breach notification and records of processing, taking into account the information available to us.
9. Personal Data Breach notification
We will notify the Customer without undue delay after becoming aware of a Personal Data Breach, with a target of notice within 48 hours of confirming it. Notice goes to the Customer’s account owners by email, and may also appear in the dashboard. The notice will describe, as far as then known, the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact for more information. Where information is not available at first, we will provide it in phases as it becomes available.
We will take reasonable steps to contain, investigate and remediate the breach and will cooperate with the Customer’s reasonable requests. Our notice of a breach is not an acknowledgement of fault or liability. The Customer is responsible for notifying Supervisory Authorities and Data Subjects where the law requires the Controller to do so, and we will not notify them on the Customer’s behalf without its agreement unless the law requires us to.
10. Deletion and return
When the Service ends, or when the Customer disconnects an app, we will delete Customer Personal Data relating to it within 30 days, unless US law requires us to keep it. Before that, the Customer may ask for an export of its Customer Data in a commonly used format. Copies in backups roll off within 35 days of the deletion of the live data, and remain protected by this DPA until they do. During the Service, Customer Data is kept only for the periods set out in Annex I.
Hashes of receipts appended to the public transparency log cannot be deleted by design. They contain no Customer Personal Data and cannot be reversed to recover it. The Customer consents to these entries under the Terms.
11. Audits and information
We will make available to the Customer all information reasonably necessary to demonstrate compliance with this DPA and Article 28 of the GDPR, including answers to a reasonable security questionnaire, our current security documentation, and a summary of any third-party assessment we have commissioned. We do not currently hold a SOC 2 report or ISO 27001 certification; if we obtain one, we will make it available under confidentiality.
If that information is not enough to demonstrate compliance, or a Supervisory Authority requires it, the Customer (or an independent auditor it appoints who is not our competitor and is bound by confidentiality) may audit our compliance with this DPA, subject to these conditions: the Customer gives at least 30 days’ written notice and a proposed scope; the audit takes place during normal business hours, no more than once in any 12 months unless after a Personal Data Breach or at a regulator’s demand; it is carried out remotely where possible and in a way that does not disrupt our operations or compromise the security or confidentiality of other customers’ data; and the Customer bears its own costs and reimburses our reasonable costs for time beyond one business day. The Customer will share the audit report with us. Audit rights over a Subprocessor are satisfied by our exercising our rights under our agreement with that Subprocessor and sharing the results we are permitted to share.
12. International transfers
Today we and all our Subprocessors process Customer Personal Data in the United States. Where Data Protection Laws restrict the transfer of Customer Personal Data from the European Economic Area, the United Kingdom or Switzerland to us:
- SCCs. The SCCs are incorporated into this DPA by reference, with Module 2 (controller to processor) applying where the Customer is a Controller and Module 3 (processor to processor) applying where the Customer is a Processor. In the SCCs: the optional docking clause in Clause 7 applies; in Clause 9, Option 2 (general written authorization) applies with the notice period in section 7.3; the optional language in Clause 11 does not apply; in Clauses 17 and 18, the governing law and courts are those of Ireland; Annex I of the SCCs is completed by Annex I of this DPA, Annex II by Annex II, and Annex III by Annex III.
- UK. For transfers from the United Kingdom, the UK Addendum is incorporated by reference. Its Tables 1 to 3 are completed with the information in this DPA and its Annexes, and in Table 4 either party may end the UK Addendum as permitted by its Section 19.
- Switzerland. For transfers from Switzerland, the SCCs apply with references to the GDPR read as references to the Swiss Federal Act on Data Protection and the competent Supervisory Authority being the Swiss Federal Data Protection and Information Commissioner.
If the SCCs conflict with this DPA, the SCCs prevail. We will not move processing of Customer Personal Data outside the United States without giving notice under section 7.3. If a recognized transfer framework we rely on is invalidated, the parties will cooperate to put an alternative lawful mechanism in place.
13. CCPA service-provider terms
Where the CCPA applies, Daryl Labs, as a Service Provider:
- will process Customer Personal Data only for the limited and specified business purposes of providing the Service described in the Terms and Annex I;
- will not Sell or Share Customer Personal Data;
- will not retain, use or disclose Customer Personal Data for any purpose, including any commercial purpose, other than those business purposes, or outside the direct business relationship between us and the Customer, except as the CCPA permits;
- will not combine Customer Personal Data with personal information received from or on behalf of another person, or collected from our own interactions with consumers, except as the CCPA permits;
- will comply with the CCPA and provide the same level of privacy protection the CCPA requires of Businesses;
- will notify the Customer if we determine we can no longer meet our obligations under the CCPA; and
- grants the Customer the right, on notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data, and to take reasonable steps to ensure we use it consistently with the Customer’s CCPA obligations, including through the information and audit rights in section 11.
We certify that we understand and will comply with these restrictions. Where another US state privacy law applies, we will meet the equivalent processor obligations of that law.
14. Liability
Each party’s liability arising out of or relating to this DPA, including the SCCs to the extent the law permits, is subject to the exclusions and limitations of liability in the Terms, including the higher cap the Terms set for our own data breaches. Nothing in this DPA limits either party’s liability to Data Subjects under the SCCs or where Data Protection Laws do not permit a limit.
15. Term, precedence and changes
This DPA lasts as long as we process Customer Personal Data. If this DPA conflicts with the Terms, this DPA prevails on the processing of Customer Personal Data. If the SCCs or UK Addendum conflict with this DPA or the Terms, the SCCs or UK Addendum prevail. Otherwise the Terms prevail. We may update this DPA to reflect changes in Data Protection Laws, in our Subprocessors under section 7.3, or in the Service, provided the update does not materially lower the protection of Customer Personal Data; we will give 30 days’ notice of any material update. This DPA is governed by the law that governs the Terms, except where the SCCs require otherwise. Questions about this DPA go to hello@getdaryl.com or the address at the end of this document.
Annex I. Description of processing
A. Parties
| Data exporter | The Customer, as identified in its account. Role: Controller (or Processor for its own client). Contact: the Customer’s account owner. |
|---|---|
| Data importer | Optiarms Inc., doing business as D.A.R.Y.L. Labs, 6545 Market Ave N, Ste 100, Canton, OH 44721, United States. Role: Processor (or Subprocessor). Contact: hello@getdaryl.com. |
| Activities | Providing the Service under the Terms. |
B. Categories of data subjects
- End users of the Customer’s apps, whose requests produce the request shapes the Service records;
- The Customer’s personnel and contractors whose names or identifiers appear in schema metadata, comments, policy text, function definitions, repository metadata or approvals; and
- Any other individual whose personal data the Customer places in Customer Data.
C. Categories of personal data
- Keyed hashes of end-user identifiers in request shapes, with the role, operation, table, filter and column names and response code of each request;
- IP addresses and user-agent strings, where the Customer’s logs include them and they are needed to build request shapes;
- Personal data incidentally contained in schema names, comments, policy text, function definitions or repository metadata; and
- Names, usernames or emails of the Customer’s personnel as they appear in connected repositories, deploy events or Slack approvals.
The Service does not process the contents of database rows. Estimated row counts are statistics, not personal data.
D. Special categories
None intended. The Service is not designed to process special categories of personal data or data relating to criminal convictions, and the Customer agrees not to place such data in the structural information the Service reads. If any is present, the measures in Annex II apply.
E. Nature and purpose of processing
Collection, storage, analysis and transmission of Customer Data in order to build an inventory of the Customer’s database structure and access policies, detect misconfigurations, draft fixes (including with an AI model, when fix drafting is in use), check fixes against Daryl’s policy model, replay recorded request shapes against old and new policies, deliver fixes by pull request or direct application, monitor canaries and roll back, issue receipts, send notifications and approvals, and provide support.
F. Duration and retention
| Data | Retention |
|---|---|
| Inventory snapshots | 13 months |
| Recorded request shapes | 30 days |
| Prior state of an applied fix | At least the 30-day undo period |
| Fixes, proofs, approvals and receipts | For the term, then deleted within 30 days |
| Connection tokens | Until disconnected or the term ends |
| Backups | Roll off within 35 days of deletion |
Processing lasts for the term of the Terms and until deletion under section 10.
G. Frequency
Continuous for as long as the Customer has an app connected: inventory scans daily, hourly or on deploy depending on plan, and request shapes ingested periodically while replay is in use.
H. Competent Supervisory Authority
Where the SCCs apply, the Supervisory Authority determined under Clause 13 of the SCCs.
Annex II. Technical and organizational measures
We maintain the following measures. They describe our practices today; where a measure belongs to a feature that may not yet be available, we say so.
| Area | Measures |
|---|---|
| Tenant isolation | Row-level security on every tenant table in our database, with the organization set per transaction, so one customer’s data cannot be read in another customer’s context. Background workers use a separately scoped role. |
| Encryption | TLS for all data in transit. Encryption at rest by our database and hosting providers. Field-level encryption of sensitive columns, including connection tokens, second-factor secrets and email addresses, with lookups by keyed blind index rather than clear text. |
| Data minimization | No copying of table rows or reading of row contents. End-user identifiers in request shapes are replaced by keyed hashes. No storage of Supabase service-role keys. Integration scopes kept to the minimum, with write access requested only when the Customer turns on apply. |
| Authentication | Mandatory two-factor authentication for every user and every member of our staff; passkeys supported; emailed sign-in links bound to the requesting browser and short-lived; step-up confirmation for sensitive actions; sessions that expire. |
| Access control | Least privilege for staff and systems; role-based access in customer organizations (owner, admin, member, billing, client viewer); production access limited to personnel who need it. |
| Accountability | An append-only audit log of approvals, settings changes, sign-ins and sensitive actions. When receipts are issued, each is signed with a key held in a key management service and not exportable from it, and its hash is appended to an append-only log. |
| Change safety | Automatic changes limited to narrowings; widening, deletion, key rotation and billing changes never automatic; AI-drafted changes flagged for human review when drafted after untrusted text. When the policy engine, replay and canary features are in use, fixes are checked against Daryl’s policy model, replayed against recorded request shapes, and rolled back to the exact prior state on a canary breach. |
| Backups and continuity | Encrypted backups with point-in-time recovery from our database provider; backups roll off within 35 days. |
| Logging and monitoring | Application and security event logging, alerts on failures, rate limits on sign-in, forms, the Check and the API. |
| Secure development | Automated tests and static checks before release; pinned dependencies; no third-party JavaScript on our site. |
| Vulnerability management | A public Vulnerability Disclosure Policy with reports to security@getdaryl.com; prompt patching of dependencies with known vulnerabilities. |
| Incident response | A defined process to triage, contain, investigate and remediate incidents, and to notify customers as section 9 requires. |
| Deletion | Deletion on disconnection and at the end of the term under section 10, retention limits applied automatically, and backups that roll off on a fixed schedule. |
| Subprocessors | Written agreements with each Subprocessor, chosen with regard to its security practices; Subprocessors located in the United States. |
| Personnel | Confidentiality obligations, and instruction in these measures, for everyone with access to Customer Personal Data. |
We do not claim SOC 2, ISO 27001 or HIPAA compliance. Our Security page describes what we do instead and is updated as our measures change.
Annex III. Subprocessors
Our authorized Subprocessors are those listed on the Subprocessors page as in effect from time to time, by role, purpose, data processed and location, as updated under section 7.3. Integrations the Customer itself connects, such as Supabase, GitHub, Slack and the Customer’s deploy platform, are not our Subprocessors; they process data under the Customer’s own agreement with them.
Contact
Optiarms Inc., doing business as D.A.R.Y.L. Labs
6545 Market Ave N, Ste 100
Canton, OH 44721
hello@getdaryl.com
Other documents: Terms · Privacy · Acceptable use · Disclosure · Subprocessors · Cookies · Hardening terms · Affiliate terms