Data Processing Addendum

Effective 26 August 2026. Last updated 26 August 2026. This Data Processing Addendum forms part of the agreement between Tasirio and its customers and applies wherever Tasirio processes personal data on a customer's behalf.

In short, for a reviewer in a hurry

• You are the controller. Tasirio is your processor for the data it reads from your systems, and a separate controller for a small set of its own records — section 3 says exactly which.
• Tasirio reads the configuration and permission model of the systems you connect, plus named business fields for two connectors. It does not read document, file, message, email or calendar content.
• Tasirio does not write to the systems it reads. It does write into outbound destinations you configure, such as your ticketing system — section 8.4 sets out both, including the case where the same system is on both sides.
• All customer data at rest is in Microsoft Azure, East US 2, United States. One region, and no other data-residency option.
• Findings and their detail are encrypted at the application layer with AES-256-GCM under a per-customer key, wrapped by a key-encryption key held only in Azure Key Vault. Section 8.2 says exactly what that does and does not cover.
• Credentials never sit in the database. They are held in a key vault and referenced, and an automated release check enforces it.
• The activity log is append-only at the database and hash-chained with a keyed HMAC. Section 8.5 states what it records and what it does not.
• Tasirio holds no SOC 2, ISO 27001 or other security certification. SOC 2 readiness work is in progress. No third-party penetration test has been performed.
• This DPA makes no availability, uptime or recovery-time commitment.

1. The parties

Effective date: 26 August 2026, or the date your subscription starts if later. Governing agreement: the Tasirio Terms of Service together with your order form and any agreement the parties have signed (the "Agreement").

2. Definitions and how this DPA fits with the Agreement

• "Customer Data" means the configuration and permission metadata Tasirio reads from the systems you connect, the findings and evidence derived from it, and the records you create in the Service — including your users and the recipients you nominate for alerts. It does not include the aggregate statistics described in section 6.3.
• "Personal Data", "processing", "controller", "processor", "data subject" and "personal data breach" have the meanings given in the applicable data-protection law.
• "Data Protection Law" means the EU GDPR, the UK GDPR and UK Data Protection Act 2018, the Swiss FADP, the California Consumer Privacy Act as amended, and any other law applicable to the processing under this DPA.
• "Sub-processor" means a third party engaged by Tasirio to process Customer Data on Tasirio's behalf.

This DPA forms part of the Agreement. If this DPA and the Agreement conflict about the processing of personal data, this DPA prevails. Where the Standard Contractual Clauses apply, they prevail over both to the extent of a conflict. Everything else in the Agreement stands.

This DPA creates no service-level, uptime or availability obligation. See section 17.

If you expect the usual annexes: Annex I (details of processing) is sections 4 and 5. Annex II (technical and organisational measures) is section 8. Annex III (sub-processors) is section 9.

3. Roles of the parties

• You are the controller of the personal data Tasirio reads from the systems you connect and of the findings derived from it. You decide which systems to connect, with what credential, which permissions to approve, when scans run, and where exports and alerts are sent.
• Tasirio is your processor for that data, including the account and sign-in records of your own administrators and the alert recipients you nominate. Tasirio processes it only to provide the Service.
• Tasirio is a separate, independent controller only for its own commercial records: the billing contact details on your account, correspondence with your people about the commercial relationship, and support tickets they raise with us. That processing is covered by Tasirio's privacy notice.
• If you are yourself a processor for someone else, Tasirio is a sub-processor and these terms apply on the same basis.

4. Subject matter, duration, nature and purpose

5. What Tasirio actually reads

Written from the connector code, not from a product description. This is the section a security reviewer should check hardest.

5.1 Categories of personal data

5.2 Categories of data subject

• Your employees, contractors and service accounts in the systems you connect.
• Guest, partner and external users present in your directory or on your shared items.
• Contact persons at your suppliers, where you connect the accounts-payable connector.
• Your own administrators who use Tasirio and the colleagues you nominate for alerts.

5.3 What Tasirio does not read

Tasirio does not read the contents of documents, files, mailboxes, chat or Teams messages, calendar entries, notebooks or attachments. It does not download file bytes.

On Microsoft 365 — the widest-reaching connector — this is enforced in code. Every request passes a single choke point that pins the HTTP method to GET; refuses any host other than Microsoft Graph; rejects a fixed list of content paths (message, mail folder, calendar, chat, contacts, attachment, photo, thumbnail, version, notebook and raw-value paths); and then requires the remaining path to match an explicit allowlist of permission and inventory endpoints. A request outside that list fails before it is sent. The authentication layer refuses outright any permission whose name matches write, manage, send, delete or full-control patterns, except one you have separately acknowledged under 8.4, and refuses to run a sync if the token it receives carries anything outside the expected read-only set.

Stated so it is not over-read: that allowlist-and-denylist mechanism is the Microsoft 365 connector's. Other connectors reach their vendors through their own read paths and read-only credentials. The commitment not to read content applies to all of them; the structural mechanism does not.

5.4 Two connectors read business record fields, and this is deliberate

• Accounts-payable automation. The payment-fraud checks you buy — duplicate bank accounts across suppliers, a supplier who can also approve their own payment — cannot be computed without supplier master data. The connector reads it, bank details included. What is stored is a partial mask of the bank identifier: for a value longer than eight characters we keep the first four and the last four; for eight characters or fewer we keep the last two. That is a partial mask, not full redaction, and we describe it that way rather than as "masked". The full identifier is used in memory to group and is not persisted. Supplier name, supplier ID, registration number and the user roster are stored.
• Dealer ERP. The opposite discipline. It reads table and column names, whether the credential can select them, and row counts. It never selects a row value. A statement such as "cardholder data is present on roughly N rows" is a count and a permission check — no cardholder value leaves your database.

5.5 Special categories of personal data

Tasirio does not ask for, and no check requires, special-category data under GDPR Article 9. Directory fields are whatever your systems hold, so a name, job title or group name you have chosen could in principle imply such a category. Tasirio does not classify or use any field on that basis. You warrant that you will not instruct Tasirio to process special-category data, and you will not place such data in fields Tasirio reads.

6. Instructions, and your responsibilities as controller

6.1 Documented instructions

Tasirio processes personal data only on your documented instructions. Your instructions are: this DPA, the Agreement, and what you configure in the Service — which systems you connect, which credential you supply, which permissions you approve, when scans run, and where you send exports, tickets and alerts.

Tasirio will tell you if, in its view, an instruction breaches Data Protection Law. That is a heads-up, not legal advice.

6.2 Your responsibilities

• You are responsible for the lawfulness of the personal data you make available to Tasirio, for having an appropriate legal basis, and for giving data subjects any notice or obtaining any consent their law requires.
• You are responsible for the accuracy of the data in your source systems. Nearly everything Tasirio holds about a person is a copy of what your directory says.
• You are responsible for having authority to connect each system and to issue each credential, and for the destinations you configure under section 9.4.
• You are responsible for your own use of the findings and reports.

6.3 What Tasirio does not do with your data — and the one carve-out

Tasirio will not process Customer Data for its own purposes, will not sell or share it, and will not use it to train any machine-learning model.

Carve-out, stated rather than assumed. Tasirio derives and retains aggregate, de-identified statistics about finding activity: finding type, connector, severity, and when an issue was first seen and resolved. That record contains no resource name, no description, no account and no user — those columns do not exist in it — and issues are linked over time by a one-way keyed identifier. Tasirio uses it for product analytics, for peer benchmarking (which returns a figure only where the cohort contains at least five organisations other than you), and for aggregate statistics it publishes about the product which never identify a customer. This carve-out is the whole of it; nothing else in the Service produces data Tasirio uses for its own purposes.

6.4 AI processing

The Service offers optional AI features that explain findings and draft remediation steps. Section 9.2 sets out exactly what reaches the model provider, and prompts are redacted before they are sent. Customer content is not used to train any model. That no-training position rests on the model provider's contractual terms, which Tasirio passes through to you; it is not something Tasirio's code can prove.

7. Confidentiality

Tasirio treats Customer Data as confidential. Access to production systems and to Customer Data is limited to named individuals who need it to run or support the Service, and they are bound by confidentiality obligations that survive their engagement.

Tasirio is a small company and does not operate a large staffed operations team. We say so rather than implying otherwise.

8. Security measures — Annex II

Everything in this section exists in code or in the running environment. Where a control has a boundary, the boundary is stated. A measure that is planned is not listed.

8.1 Tenant isolation

• Governed data — findings, remediation records, and the permission metadata collected from your systems — is isolated by PostgreSQL row-level security, enabled and FORCED. Every row carries a tenant identifier; every unit of work opens a transaction, sets the tenant, and the database policy filters on it. FORCE means the policy applies even to the table's owner.
• The application connects as a restricted database role that is not a superuser and does not hold BYPASSRLS. The migration that provisions the role refuses to run if it ever gains either.
• Platform records are isolated differently, and this is stated rather than blurred. Your connector settings, sync jobs, credential references and alert recipients live in a separate schema not under row-level security. They are isolated by an explicit tenant filter in every query, under the same restricted role, with a build check that fails if a query against the notification tables omits it. That is application-enforced isolation; the governed data above is database-enforced. Both are real. They are not the same control and Tasirio will not describe them as one.

8.2 Encryption

• In transit. TLS to every vendor API, with HTTP redirects refused so a redirect cannot carry your credential to another host. TLS to the database, required by both the client and the server. HTTPS-only storage, minimum TLS 1.2.
• At rest, platform layer. Azure service encryption, AES-256, Microsoft-managed keys. The database does not use a customer-managed key. Evidence storage additionally has infrastructure (double) encryption enabled.
• At rest, application layer. Finding detail is encrypted before it is written, with AES-256-GCM under a data key unique to your tenant. That data key is wrapped by a key-encryption key held only in Azure Key Vault, never in the database. So the database holds wrapped keys and ciphertext and nothing else: a database compromise alone yields no readable findings, and a vault compromise alone yields no ciphertext. Columns that must remain joinable are stored as a keyed HMAC blind index, not a plain hash, so they cannot be dictionary-attacked without the vault-held key. A decryption failure raises an error; there is no silent fall back to plaintext.
• The one hardware claim we make, and its exact scope. The governance key-encryption key is wrapped by a non-exportable RSA-HSM key in Azure Key Vault Premium and is unwrapped inside that hardware boundary. That claim covers the key-encryption key and nothing else. Connector credentials and customer-supplied keys are stored as key-vault secrets, which are software-protected on every Key Vault tier — Tasirio does not describe them as hardware-protected, and no bring-your-own-key material is HSM-protected.
• The boundary. Application-layer encryption covers findings (resource, description and evidence), remediation state, remediation events, exceptions and alerts. It does not cover the connector tables holding names, work email addresses and group membership. Those are protected by row-level security and platform encryption at rest. Any statement that "all customer metadata is encrypted with per-customer keys" would be false, and this DPA does not make it.
• Key custody, and what it means if a key is lost. The key-encryption key and the audit-chain key exist only in the vault. If they were destroyed, findings encrypted under them would be permanently unreadable and the activity chain unverifiable — a database restore would not help.

8.3 Credentials

• The credential you supply goes straight to Azure Key Vault. The database holds only the secret's name. The value is fetched into memory at sync time and is not returned by the API or written into an error message.
• An automated check in the release process fails the deployment if any connector field that looks like a credential is routed anywhere other than the vault.
• Bring your own key has two modes and they are materially different. In customer-key mode you generate, supply, rotate and revoke the key, but it sits in Tasirio's vault so unattended syncs keep working — you control it, Tasirio has operational custody. In bring-your-own-vault mode (Azure Key Vault, AWS Secrets Manager, Google Secret Manager, Oracle Vault) the secrets stay in your vault and Tasirio holds only a scoped, revocable access credential. In both modes, deleting the key or revoking the access makes the stored secrets unreadable. The own-cloud vault integrations are supported and are certified with you during onboarding; the Oracle Vault integration is in beta and sits within the Agreement's early-access treatment.
• You can revoke Tasirio's access in your own system at any time without Tasirio's involvement. That is the fastest kill switch and it is entirely yours.

8.4 Read-only operation, and where Tasirio does write

• Tasirio does not create, modify or delete data in the systems it reads. No connector contains a mutating call to a vendor — no PUT, PATCH or DELETE, no create, update or delete SDK command. Where POST is used it is because the vendor's read operation requires it: an OAuth token exchange, a query API that takes a request body.
• Tasirio does write into outbound destinations you configure. If you connect a ticketing system, Tasirio creates issues in Jira, incidents in ServiceNow and tickets in Zendesk and Syncro; updates their status as a finding's status changes; and adds comments or work notes. It posts to Slack and to generic webhooks you nominate. This happens with credentials you supply, at your instruction, into destinations you control. Where the same system is both governed by Tasirio and used as your ticket destination — ServiceNow and Zendesk can be both — Tasirio reads it under the first bullet and writes to it under this one.
• Authentication. Most connectors use a credential issued to Tasirio. A few vendors expose the needed data only through delegation: for Google Workspace, Tasirio signs as a service account and acts as an administrator you designate in your own domain, using read-only scopes; DocuSign uses a similar impersonation grant. You choose the account and can revoke it. This is disclosed because "Tasirio never acts as one of your users" would not be true, even though Tasirio never does it in order to test access.
• Permissions with write-sounding names. Some vendors gate read-only data behind a permission whose name implies write access and publish no read-only alternative — reading SharePoint site permission grants needs Microsoft's full-control permission, and a small number of other connectors have similar cases. Tasirio does not silently decline these; declining is not free, and quietly collecting less is not the same as looking and finding nothing. Before the permission is granted you are shown what it is for, what it unlocks, why no read-only version exists, what is still not collected even with it, and what stays dark if you decline. You must acknowledge it explicitly; consent is never inferred from the grant existing, and a tenant holding such a permission without an acknowledgement will not have it used.
• For every connector that holds such a permission, a build check fails the deployment if the connector's code could issue any non-GET call, and the connector must pin its HTTP method at a single fetch choke point.
• The boundary, stated plainly: that build check covers the connectors declaring an elevated permission, and it scans connector code only — it does not cover the outbound ticketing integrations described above, which are meant to write. The remaining connectors are protected by holding read-only credentials, meaning a write would be refused by the vendor rather than by Tasirio's code. No mutating call exists in any of them today, but that is a measured state, not a compiled guarantee. Tasirio will not claim "the build fails if any connector stops being read-only".
• The only thing Tasirio writes outside its own database that is not a destination you configured is your credential, into a key vault — yours or ours — so it never sits in a database.

8.5 Activity log

• Each completed synchronisation Tasirio runs against your systems is recorded: which connection, which surfaces were read, how much was collected, and which checks could not run. Discrete administrative actions are recorded too — exceptions created or revoked, export destinations changed, share links created or revoked, notification and policy changes, permission acknowledgements.
• The log is append-only at the database: the application role has UPDATE and DELETE revoked on it, so a compromised application or an injection cannot rewrite or truncate history.
• Each entry is chained with a keyed HMAC-SHA-256 over the previous entry and the canonical record, using a key held only in Azure Key Vault. An actor with full database write cannot forge a valid chain. The chain ratchets: once keyed it cannot be downgraded.
• Walking a chain only proves the surviving entries are unbroken, so the chain head is also mirrored outside the database, into Key Vault, which is what makes deletion of the tail detectable.
• Three honest limits. (a) It records each completed sync and each administrative action — not each individual API call. Tasirio will not say "every read is logged". (b) A synchronisation that fails part-way writes no entry; the failure is recorded on the connection's status instead. So the log is a record of what Tasirio successfully read, not of every attempt. (c) The external anchor is refreshed periodically, not on every entry, so entries since the last anchor are not truncation-protected; verification reports how stale the anchor is, so the gap is never silent.
• The log is tamper-evident. Because Tasirio holds the HMAC key you cannot recompute it yourself; Tasirio will run and evidence a verification on request.

8.6 Network and access controls

• Any host address you type is checked against internal, loopback and cloud-metadata ranges. Where the target has a vendor-owned domain, it is additionally locked to that vendor's own registrable domain with an anchored pattern or an exact host set, so a credential cannot be sent to a look-alike domain.
• Three transports are genuinely customer-hosted — on-premises SQL Server, self-hosted dealer ERP, and on-premises Oracle REST endpoints. For those there is no vendor domain to anchor to, and the only guarantee available is that the address is not one of ours. That check runs on every sync rather than only when you save the address, because a name that resolved publicly at save time can be re-pointed later. Tasirio will not claim vendor-domain locking for those transports.
• Systems behind your firewall are read by an outbound-only collector agent running on your side, posting results out to Tasirio. No inbound firewall rule is opened and the database credential never leaves your premises. The agent sits within the Agreement's early-access treatment.
• Tasirio's application authenticates to Azure with a managed identity. There are no static cloud credentials in the application.
• Evidence storage has public access disabled and issues no shareable storage links; downloads are proxied through the authenticated application.
• Staff access to production is by named account, granted only to people who need it, and removed when they no longer do.

8.7 Backups and the ability to restore

• The database has automated point-in-time backups with 35 days retention, in the same region. Geo-redundant backup is not enabled. Evidence storage is locally redundant, with 30-day soft delete and versioning enabled.
• Restore procedures are tested against a separate server, with production never modified. Testing a restore is not a commitment: this DPA offers no recovery-time or recovery-point objective.
• Consequence for deletion: data you have asked Tasirio to delete may persist in a backup for up to 35 days before it ages out. Backups are restored only for disaster recovery, never to retrieve data deleted on request.

8.8 Change control

Deployments are manual and versioned. A pre-flight check aborts the deployment on a credential-hygiene violation or a dependency-vulnerability regression. Database changes are versioned migrations. Source is held in a private repository; the sample data committed alongside the code is shape-only — field names, types and count buckets — and an automated check in the build rejects it if it carries identifiers, quoted values or token-shaped strings.

8.9 What Tasirio does not claim

• No security certification. Tasirio holds no SOC 2 report, no ISO 27001 or ISO 42001 certificate, and no HIPAA attestation. It has completed an internal self-assessment against the SOC 2 criteria and SOC 2 readiness work is in progress. No examination has begun and no report exists.
• No third-party penetration test has been performed.
• No continuous monitoring. See the Frequency row in section 4 for what actually runs.
• No in-tenant or self-hosted deployment. The Service runs only in Tasirio's own Azure environment.
• Findings are not a compliance certification. Tasirio maps findings to publicly described control themes to help you prioritise. That is not an audit opinion and attests conformance with nothing. Tasirio is independent and is not affiliated with, endorsed by or sponsored by NIST, ISO/IEC, the PCI Security Standards Council, the European Union or any other standards body, regulator or insurer.
• An absence of findings is not an assurance of security. It means Tasirio looked at what it could reach and saw nothing. Where a permission was declined, a surface could not be read, or a check did not run, the Service reports that surface as "not assessed" rather than clean.

9. Sub-processors — Annex III

You give general authorisation for Tasirio to engage the sub-processors below. The current list is also published at our sub-processors page.

9.1 Part A — may process Customer Data

9.2 What reaches the AI model, precisely

• The AI features are optional. If they are not used, nothing is sent to the model provider at all.
• What is sent is finding types, severities and counts, plus the question a user types. Prompts are redacted before they leave: identifiers are removed or replaced with placeholders.
• No document, file, message, email, calendar or record content is sent to any model, on any path.
• Customer content is not used to train any model. That position rests on the model provider's contractual terms and is passed through to you; it is not something Tasirio's code can prove.

This DPA names the provider, not the model version. A model name written into a contract is a hand-typed copy of a deployed value with no mechanism to stay true.

9.3 Part B — process only Tasirio's own business records, never Customer Data

9.4 Part C — not sub-processors

• GitHub — private source-code hosting. No Customer Data.
• Destinations you configure — your security-monitoring platform, your ticketing system, your chat webhook, your own cloud key vault. Tasirio transmits to these, and creates and updates records in your ticketing system, on your instruction. You choose the recipient and Tasirio is not the controller of that onward processing. Findings sent to a security-monitoring platform include the decrypted resource and description.

9.5 Sub-processor obligations, notice and objection

• Tasirio will impose data-protection obligations on each Sub-processor that are no less protective than those in this DPA, by written contract, and remains fully liable to you for each Sub-processor's performance of those obligations.
• Tasirio will give you at least 30 days' notice before a new or replacement Sub-processor begins processing Customer Data, by email to your nominated notification address and by updating its published sub-processor page.
• You may object on reasonable data-protection grounds within that 30-day notice period. The parties will work in good faith to resolve it. If they cannot, you may terminate the affected part of the Service without penalty for the remainder of the term; and where the objection concerns a Sub-processor that cannot be separated from the Service, you may terminate the Agreement in full and receive a pro-rata refund of prepaid fees for the unused period.
• Where a Sub-processor must be replaced urgently — for example it ceases operating or presents a security risk — Tasirio may make the change and notify you as soon as it reasonably can, with the reason, and your objection right then runs from that notice.

10. International transfers

All Customer Data at rest is held in Microsoft Azure, East US 2, in the United States. Tasirio operates a single region and offers no other data-residency option. There is no EU, UK or Canadian hosting.

Two qualifications, stated because a reviewer will find them anyway:

• Transactional email and text messages are processed by Brevo in the European Union, so an alert email — which carries finding severity, title and the affected resource name — is transferred from the United States to the European Union. You control who receives alerts and can turn alerting off.
• Website visitors. Bot protection on Tasirio's public site involves a United States provider. This concerns visitors to tasirio.com, not your employees' data.

Transfer mechanism. Where you are established in the EEA, the UK or Switzerland, or are otherwise subject to a law restricting transfers, the parties incorporate the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Two (controller to processor), with the annexes populated by sections 5, 8 and 9 of this DPA. The options are selected as follows:

• Clause 7 (docking clause): applies.
• Clause 9 (sub-processors): Option 2, general written authorisation, with the notice period in section 9.5.
• Clause 11 (redress): the optional independent dispute-resolution provision does not apply.
• Clause 17 (governing law): the law of Ireland.
• Clause 18(b) (forum and jurisdiction): the courts of Ireland.
• United Kingdom: the ICO's International Data Transfer Addendum (Version B1.0) applies to the Clauses, with the information in Part 1 taken from this DPA, and Tasirio may end the Addendum as set out in its Section 19.
• Switzerland: references to the GDPR are read as references to the Swiss FADP; the competent authority is the Swiss Federal Data Protection and Information Commissioner; "member state" is read so that Swiss data subjects may enforce their rights in Switzerland.

Tasirio is not certified under the EU–US Data Privacy Framework and does not rely on it.

Tasirio will tell you if it receives a legally binding request from a public authority for Customer Data, unless legally prohibited, and will challenge over-broad requests.

11. Helping you answer data-subject requests

Tasirio has no direct relationship with the people whose data it processes for you. If a request reaches Tasirio it will be redirected to you and not answered directly.

Tasirio will help you by, on your documented instruction: searching for what is held about an identified person; exporting it; and correcting or deleting it, subject to section 13. Tasirio will respond within 10 business days, and faster where your own statutory deadline requires it. This assistance is included in the fees you already pay; there is no separate charge for it.

One practical point: nearly everything Tasirio holds about a person is a copy of what your own directory says. Correcting it at source and running a new scan is usually the fastest fix.

12. Personal data breach

If Tasirio becomes aware of a personal data breach affecting Customer Data in Tasirio's systems, it will notify you without undue delay, and in any event no later than 72 hours after becoming aware.

The notice will describe what Tasirio knows at the time: the nature of the breach, the categories and approximate number of data subjects and records affected if known, the likely consequences, the measures taken or proposed, and a contact point. Tasirio will not delay the first notice to complete its investigation and will send updates as facts are established. A notification is not an acknowledgement of fault or liability.

You remain responsible for notifying regulators and data subjects. Tasirio will provide the information you reasonably need to do so. Section 20 of the Agreement covers security incidents that do not involve personal data.

For clarity: a finding about your own environment — an over-shared site, an over-privileged account — is the Service working as intended. It is not a breach of Tasirio's systems and does not trigger this section.

13. Retention, deletion and return

Retention is not one number, and a single figure would be contradicted by three parts of the system. It is stated per data type.

Return. While your account is active you can export your data yourself — findings and exposure reports as CSV, evidence manifests as JSON, and evidence packs. On written request Tasirio will provide a final export within 30 days, in the formats the Service supports at that time.

14. Audit and information rights

Tasirio holds no third-party audit report. This section states what it can actually do rather than a clause it would breach on first use.

Standing rights, at no charge:

• This DPA, including sections 8 and 9, is the description of Tasirio's technical and organisational measures. It is kept current.
• Once per twelve months, Tasirio will complete your security questionnaire and provide reasonable supporting documentation within 30 days of your request. Where Tasirio holds any third-party report or certification, it will make it available to you under NDA.
• Tasirio will notify you of a material change to its security measures that reduces protection.
• You can view your recent activity-log entries in the product at any time, without asking. The in-product view returns the most recent entries only, up to a fixed limit; there is no self-service full export today. On request Tasirio will provide a complete export of your activity log, and a verification of its hash chain, within 30 days.

On-site or third-party audit: where the information above is genuinely insufficient to demonstrate compliance, an on-site audit is available by agreement between the parties, no more than once in any twelve-month period, on 30 days' written notice, under NDA, during business hours, scoped to systems that process your data, and conducted so as not to disrupt the Service or expose another customer's data. The audit is at your cost, including Tasirio's reasonable costs of supporting it. Penetration testing of production requires separate written agreement and a scope both parties sign. Nothing in this section limits an audit right that Data Protection Law makes mandatory.

15. Impact assessments

Tasirio will give you the information reasonably available to it to help with a data protection impact assessment or a prior consultation with a supervisory authority, to the extent the assessment concerns Tasirio's processing. Sections 5, 8 and 9 are designed to be usable directly in one.

16. California and other US state privacy laws

Where the California Consumer Privacy Act as amended applies, Tasirio acts as a service provider and you are the business. Tasirio: (a) processes personal information only to perform the Service under the Agreement and for no other purpose; (b) will not sell or share personal information as those terms are defined; (c) will not retain, use or disclose personal information outside the direct business relationship or for a commercial purpose other than performing the Service; (d) will not combine personal information received from you with personal information received from another source, except as permitted; and (e) will comply with the applicable obligations and provide the same level of privacy protection the Act requires. Tasirio will notify you if it determines it can no longer meet these obligations. You may take reasonable steps to stop and remediate unauthorised use.

Where the Virginia, Colorado, Connecticut, Texas or other US state privacy laws apply, Tasirio acts as a processor on your documented instructions and gives the equivalent commitments: it processes personal data only for the purposes you specify, maintains the confidentiality obligations in section 7 and the security measures in section 8, engages sub-processors only under section 9.5, assists with data-subject requests under section 11, deletes or returns personal data under section 13, and makes available the information needed to demonstrate compliance under section 14.

17. What this DPA does not promise

• No availability commitment. This DPA contains no uptime percentage, no service-level agreement, and no recovery-time or recovery-point objective.
• No certification. See 8.9.
• No warranty that findings are complete. Tasirio reports what it observed and states plainly what it could not observe. A surface it could not read is reported as not assessed, never as clean.
• No legal or compliance advice. Framework mappings are for prioritisation.
• No claim about who actually accessed data. Tasirio computes who can reach data from the permission model. It does not ingest vendor access logs and cannot tell you who did. No report, order form or statement of work may imply otherwise.

18. General

• Order of precedence: for the processing of personal data — this DPA, then the Agreement. Where the Standard Contractual Clauses apply, they prevail over both to the extent of a conflict.
• Changes: Tasirio may update this DPA to reflect a change in law, in its sub-processors, or in its security measures, on 30 days' notice, provided the update does not materially reduce protection. A change that materially reduces protection requires your agreement.
• Severability: if a provision is held invalid or unenforceable, it is limited to the minimum extent necessary and the rest remains in force.
• Notices to Tasirio: privacy@tasirio.com and security@tasirio.com. Notices to you: the notification address on your account.
• Governing law and venue: the laws of the State of Texas, with exclusive jurisdiction in the state and federal courts of Tarrant County, Texas — except that where the Standard Contractual Clauses apply, the law and forum selected in section 10 (Ireland) govern those Clauses.
• Liability: each party's liability under this DPA is subject to the limitations and exclusions in the Agreement, which cap each party's total aggregate liability at the fees paid or owed in the twelve months before the event giving rise to the claim, with the carve-outs stated there.
• Survival: sections 2, 6.3, 7, 10, 12, 13, 16, 17 and 18 survive termination.

Questions

Privacy and data-protection questions: privacy@tasirio.com. Security: security@tasirio.com.

Related: Privacy Policy · Terms of Service · Data Processing Addendum · Sub-processors · Security & Trust