Ordainer Data Processing Addendum

Version: Beta preview 2026-10-09. Last updated: October 9, 2026.

This Data Processing Addendum ("DPA") is part of the Ordainer Terms of Service (the "Terms") between Ordainer ("we", "us", the "Processor"), a business based in Ottawa, Ontario, Canada, and the customer that accepted the Terms ("you", the "Customer"). It applies automatically when you accept the Terms. Until our company is incorporated, Ordainer is run as an unincorporated business. When our company is incorporated, this DPA and our obligations under it transfer to it, and we will tell you by email (Terms section 21.2). You can ask us at any time for the full legal name and address of the person operating Ordainer: email support@ordainer.ai. Words defined in the Terms (such as Service, End Customer, Agent Key, Plan, Decision, Decision Record, Customer Data and Subscription End Date) have the same meaning here.

1. Definitions

In this DPA:

• "Data Protection Laws" means all privacy and data protection laws that apply to the processing of Customer Personal Data under the Terms, which may include: Canada's Personal Information Protection and Electronic Documents Act ("PIPEDA"); Quebec's Act respecting the protection of personal information in the private sector (as amended by "Law 25"); the EU General Data Protection Regulation ("GDPR"); the UK GDPR and Data Protection Act 2018 ("UK GDPR"); and US state privacy laws, including the California Consumer Privacy Act as amended ("CCPA").
• "Customer Personal Data" means any personal information (or personal data) in Customer Data that we process on your behalf under the Terms.
• "Security Incident" means a breach of security that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data. It includes a "breach of security safeguards" under PIPEDA and a "confidentiality incident" under Quebec law.
• "Sub-processor" means a third party we engage to process Customer Personal Data.
• "Data Subject" means the individual a piece of Customer Personal Data is about.
• "Controller", "processor", "processing", "business", "service provider", "sell" and "share" have the meanings given in the Data Protection Laws.

2. Scope and roles

2.1 Scope. This DPA applies to Customer Personal Data. It does not apply to Account Data (such as your account owner's email address and billing details). We are the controller of Account Data, and our Privacy Policy covers it.

2.2 Roles. You are the controller (or, under the CCPA, the "business") of Customer Personal Data. We are your processor (or "service provider"). If you are yourself acting as a processor for someone else, you confirm that your instructions are authorised by that controller, and we act as your sub-processor.

2.3 Details. Annex 1 describes the processing.

2.4 Beta. During the beta, we process Customer Personal Data on our beta environment, hosted by Render and Neon in the United States (Ohio region). Decision Records are kept for 90 days. Our database has 7-day point-in-time recovery; there is no off-site backup copy yet (section 11.5).

3. Your responsibilities

3.1 You are responsible for: having a lawful basis for the Customer Personal Data you send us; giving any notices to, and getting any consents from, Data Subjects that Data Protection Laws require; and the accuracy of Customer Data.

3.2 Keep it minimal. The Service does not need people's names to work. You will use pseudonymous identifiers rather than personal names or contact details in End Customer names, external IDs, key labels, tool names and idempotency keys wherever you can, and will not send special category, sensitive or highly confidential personal information in any field. Please use pseudonymous End Customer IDs (not names or email addresses) where you can.

3.3 You are responsible for any assessments Data Protection Laws require of you, including any Quebec transfer assessment before Customer Personal Data about Quebec residents leaves Quebec. We will give you the information in section 10 to help.

4. Processing only on your instructions

4.1 We will process Customer Personal Data only on your documented instructions, unless the law requires otherwise (in which case we will tell you first, unless the law forbids it).

4.2 Your documented instructions are: (a) the Terms and this DPA; (b) your configuration of the Service in the console (customers, Plans, keys, modes, exports, sandbox resets); and (c) your product's API calls to the Service. Any further instruction must be in writing and consistent with the Terms.

4.3 We will tell you if, in our opinion, an instruction breaks Data Protection Laws. We may then suspend that processing until you change or confirm the instruction.

5. Confidentiality

We will make sure that everyone we authorise to process Customer Personal Data is bound by a duty of confidentiality (by contract or by law) and processes it only as needed to provide, secure and support the Service.

6. Security

6.1 We will put in place and maintain the technical and organisational measures in Annex 2, which are designed to protect Customer Personal Data against Security Incidents, taking into account the state of the art, cost, and the nature, scope, context, purpose and risks of the processing.

6.2 We may update these measures as long as the overall level of protection is not reduced.

6.3 We do not hold any security certification (such as SOC 2 or ISO 27001) today.

7. Sub-processors

7.1 General authorisation. You authorise us to use the Sub-processors listed in Annex 3.

7.2 Contracts. Before a Sub-processor processes Customer Personal Data, we will have a written contract with it that imposes data protection duties no less protective than this DPA, to the extent they apply to the service it provides. We remain responsible to you for our Sub-processors' performance of those duties.

7.3 Notice of changes. We will tell you about any new or replacement Sub-processor at least 30 days before it starts processing Customer Personal Data, or, for changes made by our providers' own sub-processors, as soon as we reasonably can after we are told. We do this by email to your account owner's email address and by updating our list at https://ordainer.ai/legal/subprocessors, which shows a "Last updated" date and a short change log. You can object under section 7.4. A change to the list does not require you to accept the Terms or this DPA again.

7.4 Your right to object. You may object on reasonable data protection grounds by emailing support@ordainer.ai with "Privacy" in the subject within that notice period. We will discuss the concern in good faith. If we cannot resolve it, you may cancel your Subscription with effect before the change, and we will refund any prepaid fees for the period after cancellation.

7.5 Emergencies. If we must replace a Sub-processor urgently (for example because it fails or stops trading), we will give notice as soon as we can, and your right to object still applies.

8. Helping you with Data Subject requests

8.1 Taking into account the nature of the processing, we will help you respond to requests from Data Subjects to exercise their rights, by appropriate technical and organisational measures where possible.

8.2 Self-service. You can view and export Decision Records (CSV or JSON) in the console, including searching by request ID, within your plan's history length.

8.3 With our help (manual in this version). The console does not yet let you edit or delete an End Customer record or change key labels. In this version of the Service we handle these requests by hand. If you need to correct or erase personal information in those fields, email support@ordainer.ai with "Privacy" in the subject. We will make the change (for example, correcting or de-identifying the End Customer name and external ID) promptly, and in time for you to meet the response deadlines that apply to you, and confirm to you in writing when it is done. Decision Records are append-only. A key label copied into Decision Records stays there until those records reach the end of their history length (or until your account is deleted, if earlier), unless we agree another approach with you.

8.4 If a Data Subject contacts us directly about Customer Personal Data, we will not respond ourselves (other than to tell them to contact you) and will pass the request to you without undue delay, if we can identify you.

9. Security Incidents

9.1 We will notify you after becoming aware of a Security Incident affecting your Customer Personal Data without undue delay, and we aim to do so within 72 hours.

9.2 Our notice will describe, as far as we know at the time: what happened; the categories and approximate number of Data Subjects and records involved; the likely consequences; and what we have done or plan to do to deal with it and reduce its effects. We will give further information as it becomes available.

9.3 We will take reasonable steps to contain and investigate the Security Incident and reduce harm, and will cooperate with you so that you can meet your own reporting and notification duties (for example to the Privacy Commissioner of Canada, the Commission d'accès à l'information du Québec, or an EU or UK authority).

9.4 We will keep a record of every Security Incident, as Canadian and Quebec law require.

9.5 Our notice is not an admission of fault or liability.

10. Assessments and consultations

We will give you reasonable information and help, taking into account the nature of the processing and the information available to us, for any data protection impact assessment, privacy impact assessment, Quebec transfer assessment, or prior consultation with a regulator that Data Protection Laws require of you about the Service.

11. Deletion and return at the end

11.1 During the Subscription. You can export Decision Records at any time in the console. Decision Records are deleted automatically when they pass your plan's history length (Annex 1, item 9).

11.2 After the Subscription ends. The Subscription End Date is the date the Subscription ends: at the end of the paid period after cancellation, or, after a failed renewal payment that is never paid, at the end of the comeback period, when we cancel the Subscription (30 days after the missed renewal date; Terms 2, 10.1 and 10.2). Live keys stop earlier, at the cutoff in Terms 10.1(d). Nothing is deleted during the comeback period. If you do not subscribe again:

• (a) from the Subscription End Date until deletion, we only hold your Customer Data, with live keys off. We process it only to store it, to let you sign in and export it, and to delete it. You can export your Decision Records at any time until deletion, within your plan's history length (Terms 11.4 and 11.6); and
• (b) 90 days after the Subscription End Date (day 120 after the missed renewal date, after an unpaid failure), we delete all your Customer Data in one step (Decision Records, the related idempotency records and usage counters, End Customer names and external IDs, Plans, Agent Key details including key hashes, prefixes and labels, and the change log), together with your account. There is no earlier purge of Decision Records after the Subscription ends. Each deletion is logged as described in Annex 2. If you subscribe again before the deletion date, nothing is deleted (you create new live keys, and old keys never work again; Terms 9.11(b)).

11.3 Account deletion and inactive free accounts. You can delete your account in the console at any time when you have no active Subscription and no Subscription with an unpaid balance that is still inside the payment window in Terms section 10.1 (whether Stripe shows it as past due or unpaid). Once live keys have stopped at the cutoff in Terms section 10.1(d), or a Subscription has ended by cancellation, you can delete the account. We then delete all Customer Data straight away. An account that has never had a paid Subscription, with no sign-in and no Decisions for 12 months, is deleted with all its Customer Data, after a warning email to the account owner 14 days before.

11.4 What remains after deletion. After an account is deleted, no Customer Personal Data remains in our database. We keep only Account Data, not Customer Data:

• (a) a deletion record (an internal account ID, the reason, the time, the number of records removed, and the Stripe customer ID, so that billing records can be matched for tax purposes), deleted 7 years after the account is deleted; and
• (b) a minimal record of the document versions you accepted and the date, with no email or IP address, deleted 3 years after the account is deleted.

Invoices and payment records are not stored in our database. Stripe keeps them, and we keep our official copy in Canada, for six years from the end of the tax year they relate to, as Canadian tax law requires.

11.5 Backups. Our database host (Neon, listed in Annex 3) keeps 7-day point-in-time recovery history, which we use only to recover the Service after a failure or error. Customer Data we delete can stay restorable from it for up to 7 days after deletion; it is then removed automatically from that history. There is no off-site backup copy yet. We plan to add a daily encrypted off-site backup with Backblaze in Canada; it isn't in use yet, and we'll update this DPA and our sub-processor list, with notice under section 7.3, before it starts. The restore history stays protected by the measures in Annex 2. (Billing records kept in Canada for tax purposes, section 11.4, are Account Data held as accounting records, not a database backup.)

11.6 Holds. We may keep Customer Personal Data longer where the law requires (for example for a legal claim), and then only for that purpose, with this DPA continuing to protect it. While an account is on hold, the automatic deletions in sections 11.2 and 11.3 are paused for that account, and records reaching the end of their history length are kept as a copy for the hold. If you delete your account yourself, that deletion still goes ahead.

12. International transfers

12.1 Where data is processed. We are in Canada. Our Sub-processors store and process Customer Personal Data in the United States (see Annex 3). You authorise these transfers, subject to this section.

12.2 From the EU. For transfers of Customer Personal Data subject to the GDPR to a country without an adequacy decision, the EU Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 ("SCCs") are incorporated into this DPA by reference: Module 2 (controller to processor) where you are a controller, and Module 3 (processor to processor) where you are a processor. For the SCCs: the optional Clause 7 (docking clause) applies; under Clause 9, option 2 (general written authorisation) applies, with the notice period in section 7.3; the optional wording in Clause 11 does not apply; the SCCs are governed by the law of Ireland (Clause 17) and disputes go to the courts of Ireland (Clause 18); and Annex I of the SCCs is Annex 1 of this DPA, Annex II is Annex 2, and Annex III is Annex 3.

12.3 From the UK. For transfers subject to the UK GDPR, the UK International Data Transfer Addendum to the EU SCCs (issued by the Information Commissioner under section 119A of the Data Protection Act 2018) is incorporated by reference, with the tables completed using the information in this DPA and its Annexes.

12.5 Onward transfers. Where a Sub-processor receives Customer Personal Data outside Canada, the EU or the UK, we will rely on a valid transfer mechanism for that transfer, such as the Sub-processor's Standard Contractual Clauses or its certification under the EU-US Data Privacy Framework and its UK extension.

12.6 Canada and Quebec. We will protect Customer Personal Data transferred outside Canada or Quebec with contractual and other measures giving a level of protection comparable to the one it would have in Canada, and will give you the information you reasonably need for any transfer assessment (section 3.3).

12.7 If the SCCs or the UK Addendum conflict with this DPA, they prevail for the transfers they cover.

13. US state privacy laws (CCPA and similar)

Where we process Customer Personal Data as a service provider or processor under the CCPA or another US state privacy law, we will:

• (a) not sell or share Customer Personal Data;
• (b) not keep, use or disclose it for any purpose (including any commercial purpose) other than the business purposes set out in the Terms and this DPA, or as the law otherwise allows;
• (c) not keep, use or disclose it outside our direct business relationship with you;
• (d) not combine it with personal information we receive from others or collect ourselves, except as the law allows for service providers;
• (e) comply with the CCPA and give Customer Personal Data the same level of privacy protection the CCPA requires;
• (f) tell you if we decide we can no longer meet our obligations under the CCPA;
• (g) let you take reasonable and appropriate steps to stop and fix any unauthorised use of Customer Personal Data; and
• (h) flow these duties down to our Sub-processors.

We certify that we understand and will comply with these restrictions. The business purpose of the processing is providing the Service described in Annex 1.

14. Audits

14.1 Questionnaire first. On written request, no more than once in any 12 months (or more often if a regulator requires it or after a Security Incident), we will answer a reasonable security and privacy questionnaire and give you documents reasonably needed to show that we comply with this DPA.

14.2 Audits. If the questionnaire and documents are not enough to show compliance, or a regulator requires it, you (or an independent auditor bound by confidentiality, who is not our competitor) may audit our compliance with this DPA. You must give at least 30 days' written notice, agree the scope, timing and duration with us in advance, carry out the audit during business hours without unreasonable disruption, and pay its costs. Audits will be remote unless an on-site audit is reasonably needed. Audits do not extend to our Sub-processors' facilities; for those we will pass on reports or information the Sub-processor makes available.

14.3 Everything you learn in a questionnaire or audit is our Confidential Information.

15. Liability

Each party's liability arising out of or relating to this DPA (including the SCCs and UK Addendum, to the extent the law allows) is subject to the exclusions and limits in the Terms (section 16 of the Terms). This does not limit any Data Subject's rights under the SCCs.

16. Term, priority and changes

16.1 This DPA lasts as long as we process Customer Personal Data, even after the Terms end.

16.2 If this DPA conflicts with the Terms on the processing of Customer Personal Data, this DPA prevails. Section 12.7 applies to the SCCs and UK Addendum.

16.3 We may update this DPA under the change process in the Terms. If we publish a new version, we will email you before it applies to you. We will not make changes that reduce the protection of Customer Personal Data unless the law requires it.

16.4 This DPA is governed by the law and courts set out in the Terms, except where the SCCs or UK Addendum require otherwise.

Annex 1: Details of the processing

1. Parties.
   • Controller (data exporter): the Customer, as identified in its account. Contact: the account owner email.
   • Processor (data importer): Ordainer, Ottawa, Ontario, Canada (unincorporated business; company to follow). Contact: Privacy Officer, support@ordainer.ai ("Privacy" in the subject).
2. Subject matter. Providing the Service: checking a Customer's End Customers' AI agents against plan limits the Customer configures, returning allow or deny before the Customer's tool runs, and keeping an audit record of each allow or deny Decision. Requests rejected without a Decision (Terms 5.1) are not recorded.
3. Duration. For the term of the Terms. After the Subscription End Date: all Customer Data, Decision Records included, for up to 90 more days (section 11.2), unless the account is deleted earlier (section 11.3).
4. Nature of the processing. Storage, counting against configured caps, decision-making (allow or deny) on the Customer's instructions, recording, display in the console, export, and deletion.
5. Purpose. To provide, secure and support the Service under the Terms.
6. Categories of Data Subjects.
   • The Customer's End Customers, where they are individuals.
   • Personnel of the Customer's End Customers, where their names or identifiers are entered as End Customer names, external IDs or key labels.
   • The Customer's own personnel, where their names appear in key labels or similar fields.
7. Categories of personal data. Only what the Customer chooses to enter or send:
   • End Customer records: name and optional external ID.
   • Plan records: plan name, tool name (or "all tools"), monthly cap, mode. (Not normally personal data.)
   • Agent Key metadata: label, environment (test or live), display prefix, created, revoked and suspended times, and the linked End Customer and Plan. The key secret is stored only as a one-way SHA-256 hash; we never store it in readable form and cannot recover it.
   • Decision Records (one per allow or deny Decision; none for requests rejected without a Decision, such as subscription_inactive, subscription_required, safety_limit_reached (shadow-mode test-key calls beyond the safety ceiling in Terms 4.2(b)) or requests that error out first, as listed in Terms 5.1): request ID, time, source (API or console), environment, linked End Customer, Agent Key and Plan, key label, tool name, decision (allow or deny), reason, remaining count, cap, period start and end, idempotency key supplied by the Customer's product, and mode (shadow or enforce).
   • Usage counters: counts of allowed Decisions per Agent Key per period.
   • Change log: a record of plan edits and moves of keys between plans (when, the before and after values, and the email of the account user who made the change).
   • No request payloads are stored. A decision request contains only the tool name, an optional idempotency key and an optional mode; it is limited to 16 KB.
   • Not Customer Personal Data: operational logs. We keep daily counts of decision requests we rejected or that failed with an error, per Customer account, day, error code and client (our SDK's name and version, or "other"), for 400 days. For every decision request that reaches us, the application also writes one log line with the request ID, our internal account ID, status, decision (if any), error code (if any), timings, and queue and limit flags, kept with our application logs (7 days at our hosting provider). Neither contains an Agent Key, an IP address or the request body. We handle them as service data under Terms 11.3 and our Privacy Policy (section 3.2(h)).
   • Not Customer Personal Data: SDK health reports. Planned, not yet in use; this note applies only if and when we build it. If the Customer uses our Node.js SDK, the SDK would send, with a decision request, daily counts of calls it could not check with us (timeouts, network errors, server errors, unreadable replies) and the slowest call time. We would store them only as daily totals per Customer account, with no End Customer, Agent Key, key label, IP address, payload or other request content attached. They would describe the Customer's integration, not any individual, so they would not be Customer Personal Data. We would handle them as service data under Terms 11.3 and our Privacy Policy. The Customer would be able to switch them off in the SDK.
8. Sensitive data. None intended. The Customer must not send sensitive or special category data (DPA section 3.2).
9. Retention.
   • Decision Records: the plan's history length (Sandbox and Starter 90 days; Growth 365 days, when offered). Records are hidden from the console and exports when they expire, and permanently deleted when the whole calendar month (UTC) containing them has expired (up to about one more month).
   • Sandbox reset: deletes the Customer's test-key Decision Records, idempotency records and test-key counters when the Customer chooses.
   • After the Subscription End Date: all Customer Data, including Decision Records, idempotency records and usage counters, is deleted 90 days later, unless the Customer resubscribes first.
   • Owner-initiated account deletion: all Customer Data deleted at once. Never-paid accounts inactive for 12 months: deleted after a 14-day warning.
   • Holds: automatic deletion is paused for an account on hold (section 11.6); owner-initiated deletion still runs.
   • End Customer correction or erasure requests: handled manually (section 8.3).
   • Backups: up to 7 days of point-in-time recovery history at Neon; no off-site backup copy yet (section 11.5).
10. Frequency. Continuous, whenever the Customer's product calls the Service.
11. Sub-processors. See Annex 3.
12. Competent supervisory authority (EU SCCs). The supervisory authority determined under Clause 13 of the SCCs.

Annex 2: Technical and organisational security measures

These are the measures the Service implements today.

Secrets and credentials

1. Agent Key secrets are 192-bit random values. They are shown to the Customer once, at creation, and stored only as SHA-256 hashes. The console shows only a short display prefix.
2. Sign-in link tokens are 256-bit random values, stored only as SHA-256 hashes, valid for 60 minutes and usable once. Opening the link does not use it up; a separate confirmation step does, so email scanners cannot use it.
3. Console session tokens are random and stored only as hashes. The session cookie is HttpOnly, Secure, SameSite=Lax and host-only (__Host- prefix), expires after 30 days, and is deleted on sign-out.
4. Application secrets (database connection, email and payment provider keys) are kept in the hosting provider's environment settings, not in source code.

Audit log integrity 5. Decision Records are append-only: a database trigger rejects any update, delete or truncate on the audit table and on every partition. 6. Decision Records are removed only by the Service's own deletion paths (plan history expiry, the deletion 90 days after a Subscription ends, account deletion, and sandbox resets). Every deletion is logged in a separate append-only ledger in the same database transaction, recording the reason, the account (where applicable), the time range, the number of records, the range of record IDs, and a SHA-256 hash of the removed request IDs, so a Customer holding an earlier export can check exactly what was removed. 7. Limitation: these controls do not prevent someone with database administrator access from changing or deleting records or the ledger, because the deletion hashes are not stored outside the database. They are a record-keeping control, not a tamper-proof guarantee.

Change log 8. Plan edits and moves of keys between plans are recorded in an append-only change log (who, when, before and after).

Separation and access 9. Every console page and export is restricted to the signed-in account's data. Database constraints stop an Agent Key from being linked to another account's End Customer or Plan. Automated tests check that exports and request-ID searches never return another account's data. 10. Each account has a single owner in this version of the Service. 11. Access to production systems and data is limited to the people who need it to run the Service.

Data minimisation 12. The Service does not store the content of the Customer's tool requests. A decision request carries only a tool name, an optional idempotency key and an optional mode, and is limited to 16 KB. 13. Our application code never stores or logs raw IP addresses. For sign-in limits, terms acceptance records and the public demo, it stores only salted one-way hashes of the IP address (Account Data under our Privacy Policy). The salt is secret: in production the application refuses to start without its own salt, and there is no public fallback. Our hosting and CDN providers process IP addresses in their own request logs (Annex 3). 14. The decision path does not call the payment or email providers.

Network and application security 15. Encryption in transit: the Service is designed to run only over HTTPS (TLS) (session cookies are Secure-only), and the database connection requires TLS. 17. Console protections: anti-forgery tokens on every form; a strict Content Security Policy that allows no scripts; framing blocked; no referrer sent (sign-in links carry a token); pages not cached; all user input escaped; spreadsheet formulas neutralised in CSV exports. 18. Abuse limits: sign-in emails are limited per email address (5 per hour) and per IP address (20 per hour); the public demo is limited per IP address (60 clicks per hour by default); decision requests are rate-limited per Agent Key, and decision requests with an invalid key are limited per IP address (per /64 for IPv6; requests with a valid key never count toward that limit and are never blocked because of other keys' failed attempts while our key check is working; see Terms 5.9). The per-IP invalid-key limit holds the IP address (IPv6: its /64 prefix) only in the application's memory, usually for about a minute after the last failed attempt and never more than 24 hours; entries are swept every 60 seconds and cleared on restart. The application never writes it to its database or logs. Our hosting and CDN providers process IP addresses in their own request logs. These limits are approximate (counted on each server separately) and may change. 19. Payment webhooks are accepted only with a valid signature and are processed once. 20. The application refuses a live payment-provider key unless deliberately enabled.

Reliability and testing 21. An automated test suite (more than 130 tests at the time of drafting) covers, among other things, key hashing, append-only enforcement, deletion logging, account separation, sign-in token handling, anti-forgery checks and cookie settings. 22. Backups and restore: the database host keeps a restore history of up to 7 days (point-in-time restore), used only to recover the Service; older history is deleted automatically. There is no off-site backup copy yet. We plan to add a daily encrypted off-site backup with Backblaze in Canada; it isn't in use yet, and we'll update this DPA and our sub-processor list before it starts. Deletions from the live database do not immediately remove data from the restore history; that history ages out on the schedule above.

Certifications 24. None. We do not hold SOC 2, ISO 27001 or any other security certification.

Annex 3: Sub-processors

Sub-processors that process Customer Personal Data

Planned, not yet in use: We plan to add a daily encrypted off-site backup with Backblaze in Canada; it isn't in use yet, and we'll update this list, with notice under section 7.3, before it starts.

Providers that do not receive Customer Personal Data (listed for transparency; they process Account Data under our Privacy Policy)

Render uses Cloudflare (United States) for its network edge; see Render's sub-processor list at https://render.com/security. Render and Cloudflare record client IP addresses in their own platform request logs.

If we use a separate host for our website or docs, it should not receive Customer Data; we will add it to the right table, with notice under section 7.3, before it goes live.