1. Introduction

This Statement provides transparency for organisations evaluating the Extension. The Extension enables teams to define automations — a trigger (Azure DevOps work item event or schedule), optional conditions, and a chain of actions — that are executed by our hosted backend inside the customer's Azure DevOps organization.

Scope. Applies only to the Azure DevOps extension "Automations" and the Documentero backend used by it. It does not cover other Documentero products.

High-Level Summary.

• The Azure DevOps organization must be connected to Microsoft Entra ID; organizations that use Microsoft personal accounts only ("MSA-only organizations") are not supported.
• Connect provisions the Workflow Automation service principal as an Azure DevOps user and adds it to Project Administrators on projects selected by a Project Collection Administrator. Automations run as this identity, never as the author.
• Runtime uses short-lived tokens obtained server-side through the Microsoft Entra client credentials flow. Azure DevOps Personal Access Tokens and organization user access or refresh tokens are not persistently stored.
• Inbound Azure DevOps events are authenticated; the receiving endpoint only validates, de-duplicates, matches, and queues work. Work item changes and emails are performed by a separate execution component.
• Extension clients can only read their organization's automations and logs; all changes go through authenticated server-side functions with access checks.
• Loop protection and usage limits reduce the risk of runaway updates.
• We keep no copy of your work items; persistent data is limited to connection metadata, automation configuration, operational metadata, and compact Execution Logs that expire after about 30 days.

1.1 Definitions

• Automation: A customer-configured workflow (trigger, optional conditions, actions) stored by the Service and scoped to one Azure DevOps project.
• Automation Identity: The Workflow Automation service principal provisioned as a user in the customer's Azure DevOps organization; all automation actions execute under this identity.
• Service Hook: An Azure DevOps outbound webhook subscription created and removed by the Service when automations need events.
• Execution / Execution Log: One run of an automation (triggered by an event, a schedule, or "Run now") and its compact record (status, timestamps, step summaries, identifiers and fields of affected work items, errors).
• Subprocessor: A third-party service used to provide infrastructure or limited processing under our control (e.g., Google Cloud, Brevo).

2. Security Approach

The Extension is designed with security in mind and focuses on protecting data during collection, processing, transmission, storage, and deletion, and on limiting what an automation can do inside a customer's Azure DevOps organization.

2.1 Infrastructure and Hosting

The Extension backend runs on Google Cloud Platform (GCP) and uses Firebase services. GCP and Firebase provide managed infrastructure and baseline protections. Key points:

• Region: Backend compute, database, task queues, and key management are located in the European Union (primary region europe-west1, Belgium). No customer data is processed by our backend outside the EU.
• Encryption in Transit: All communication between Azure DevOps, the Extension UI, backend services, and subprocessors is encrypted using HTTPS/TLS.
• Encryption at Rest: All Google Cloud services used encrypt data at rest using Google-managed encryption keys.
• Credentials: Documentero service credentials are held in protected server-side storage and are not included in the Extension package or exposed to Extension users.
• Logical Data Isolation: Data is partitioned per Azure DevOps organization; backend access checks enforce that sessions only reach their own organization's records.

2.2 Authentication and Identity

The Service distinguishes between the signed-in user operating the Extension UI and the Automation Identity executing actions.

No Azure DevOps passwords, Personal Access Tokens, or persistent organization user access or refresh tokens are collected or stored.

2.3 Access Control

• Organization level: Only Project Collection Administrators can use Connect, Manage projects, Verify, or Disconnect, or set the organization contact email.
• Automation Identity: Connect adds the service-principal user with Stakeholder access and Project Administrators membership on selected projects. It is not made a Project Collection Administrator. Removing a project through Manage projects pauses executions there and removes the related project access.
• Project-level UI access: Project Administrators may manage Automations by default and may allow additional Azure DevOps groups. Project members may view Automations and Execution Logs unless that access is restricted.
• Fail closed: If access evaluation fails, the backend denies access rather than granting it.
• Execution ceiling: An automation can never do more in Azure DevOps than the Automation Identity is permitted to do in a selected project.
• Project isolation: Automations belong to a single team project. Query results from other projects are dropped, and parent/child operations that would cross project boundaries fail rather than proceed.
• Client is read-only: Every write (create, update, enable, delete, connect, settings) is performed by authenticated server-side functions that re-check permissions.
• Documentero personnel: Access to production systems is limited to authorised team members and enforced using role-based controls.

2.4 Event Handling and Execution Safety

• Thin receiver: The public endpoint that receives Azure DevOps events only authenticates the request, de-duplicates it, matches enabled automations, and queues work. It does not modify work items or send email.
• Queued execution: Actions are executed by a separate component with per-step idempotency and retries with backoff. Runs fail permanently (and are logged) when the Automation Identity is not ready, the project is not selected, or the organization or automation has been disabled.
• Loop protection: The Service records which automation caused a work item revision, limits cascade depth between automations, skips self-triggering and cyclic patterns, and conservatively skips events changed by the Automation Identity without a known cause.
• Usage limits: Default limits include 50 automations per organization, 500 executions per organization per UTC day, 250 executions per project per UTC day, 200 work items loaded per search or query, and 50 work items modified per run. Over-limit events are skipped and acknowledged to Azure DevOps so that Service Hook subscriptions are not disabled by Microsoft.
• Organization disable: Documentero can stop new executions for an organization during an incident or in case of abuse.
• Service Hook hygiene: Subscriptions are created and removed automatically as automations are enabled or disabled, and their configuration is reconciled periodically.

2.5 Information Security Management Practices

Logging and Monitoring

• Backend systems record logs for key events (authentication, errors, and unusual behavior) to support troubleshooting and security analysis.
• Logs are accessible only to authorised team members and used for operational monitoring and incident investigation.
• Indicative retention: operational logs ≈30 days; security/authentication events ≈90 days (subject to adjustment). Older logs are purged automatically.
• We avoid logging work item bodies, comment text, or email content; diagnostic metadata is minimized.

Code Reviews

• Code review is part of the development process, with scope based on the type and risk of the change.

Dependency and Vulnerability Management

• Periodic reviews of third-party dependencies; urgent issues addressed on a risk basis.
• Security reports and vulnerability information are received via support@documentero.com, investigated, validated, and prioritized based on severity; fixes are deployed as appropriate.

User Notification of Security Issues

• Where notification is required by applicable law or agreement, Documentero may use the organization contact email or another appropriate channel and provide the information reasonably available at that time.

3. Data Handling and Processing

The Extension processes a minimal set of data necessary for functionality. Persistent storage is limited to connection metadata, customer-authored automation configuration, operational metadata, and compact execution records. We do not store copies of your work items; changes made by automations are written directly to your Azure DevOps organization.

• Connection metadata includes the Microsoft Entra tenant identifier, Automation Identity summary, selected projects, and connection status. It is cleared by Disconnect.
• Automation definitions and settings are retained until deleted by the customer.
• Execution Logs contain compact run and step summaries and expire after approximately 30 days.
• Event data is processed to match and run Automations; short-lived duplicate-detection and loop-protection markers are retained for up to 7 days.
• Email content and recipients are sent to the email provider only when the customer configures an email action; Documentero does not keep a sent-email archive.

See the Privacy Policy for the full data inventory and retention periods.

4. Data Protection and Privacy

4.1 Privacy Principles

• Data minimization — only the data needed to match and run automations is processed; work items are not mirrored.
• Purpose limitation — data is used only to run customer-configured automations and to operate, secure, and support the Service.
• User control — automations can be disabled or deleted by authorized members; an Organization Administrator can manage selected projects or Disconnect the Automation Identity.

4.2 Third-Party Sharing & Subprocessors

Data is not sold or shared with external parties for their own purposes. The current subprocessors used for infrastructure and email delivery are:

Microsoft (Azure DevOps, Microsoft Entra ID) is the customer's own platform and identity provider. The Service calls Microsoft APIs on the customer's behalf; Microsoft processes that data under the customer's agreement with Microsoft rather than as our subprocessor.

This list may be updated as the Service changes. The Privacy Policy contains the current privacy-related subprocessor information.

5. Shared Responsibility

Automations act inside the customer's Azure DevOps organization with the permissions the customer grants. Security of the overall solution therefore depends on both Documentero and the customer. Customers are responsible for:

• Entra eligibility: Ensure the Azure DevOps organization is connected to Microsoft Entra ID and Connect uses that same directory.
• Project selection: Select only projects where the Automation Identity should receive Project Administrators membership. The identity consumes an Azure DevOps Stakeholder seat while it remains under Users.
• Controlling who can author automations: Review the project access settings. Project Administrators manage by default and may allow additional groups. Anything the Automation Identity can do in a selected project can be caused by an authorized author.
• Reviewing and testing automations: Verify triggers, conditions, target scope, and email recipients before enabling; prefer a non-production project for evaluation. The Service cannot roll back changes; use Azure DevOps work item history.
• Email recipients and content: Ensure a lawful basis exists for each recipient and avoid including sensitive data in email templates.
• Monitoring and lifecycle: Check Execution Logs for failed or skipped runs, review selected-project access, and disable or delete Automations that are no longer needed.

Disconnect clears Documentero's connection state and removes Service Hooks created by Documentero. To complete offboarding, delete the Automation Identity under Azure DevOps Users to release its seat and, if desired, disable or remove the Enterprise application in Microsoft Entra. Disconnect does not perform those removal steps. Once disconnected, a remaining user does not continue to execute Automations, but it may prevent a later Connect from completing.

6. Incident Response

On detection of a security or privacy issue, our internal process aims (without guaranteeing specific timelines) to follow these phases:

• Detection & Triage: Identify indicators; initial assessment.
• Containment: Limit scope and prevent further impact (including, where needed, pausing executions for affected organizations).
• Eradication & Remediation: Fix root cause; deploy patches or configuration changes; rotate affected service credentials where relevant.
• Recovery: Validate service integrity and monitor for recurrence.
• Notification: Notify affected organizations where required by applicable law or agreement, based on the information reasonably available.
• Post‑Incident Review: Document lessons learned and track follow‑up improvements.

7. Contact and Data Protection Requests

For security, privacy, or data protection questions and requests (access, deletion, portability, etc.), please contact:

Email: support@documentero.com

8. Responsible Disclosure

We welcome good-faith security reports. Please avoid tests that degrade availability, trigger automations in organizations you do not control, or access other customers' data. Report potential vulnerabilities to support@documentero.com. Do not include sensitive data in reports. We review submissions, assess severity, and, where appropriate, implement fixes. While we cannot offer formal bug bounty payments at this time, we appreciate the community's efforts to improve security.

9. Preview Status and Current Limitations

• The Extension is in Preview. Features, limits, and behavior may change, and no availability or support service level commitment applies.
• We do not hold SOC 2, ISO 27001, or similar certifications and do not publish penetration test reports.
• There is currently no customer-selectable processing region; the backend is hosted in the EU only.
• No payment or card data is processed (the Extension is currently free of charge).
• Delivery of every Azure DevOps event is not guaranteed: Microsoft's Service Hook delivery, duplicate detection, loop protection, and usage limits may cause runs to be skipped or delayed.

10. Updates & Change Tracking

Documentero may update this Statement as the Service changes, including when the Extension leaves Preview. Changes take effect when posted or on any later date stated in the updated Statement. The version and Last Updated date identify the current published version. For privacy rights and broader data handling details, consult the Privacy Policy at documentero.com/privacy-policy-ado-automations.