Security & Data Protection Statement

"Automations" Azure DevOps Extension

Version: 1.3   Last Updated: 15 October 2026

Security & Data Protection Statement for the Azure DevOps Extension – "Automations"

Effective Date: September 3, 2026

This Statement explains how the Documentero "Automations" Azure DevOps extension (the "Extension") and its hosted backend manage security, data handling, and user privacy. It complements the Privacy Policy at documentero.com/privacy-policy-ado-automations.

We aim to follow widely adopted good practices (access control, encryption, logging, vulnerability management, peer review) appropriate to our size and risk profile. We do not currently hold external certifications (e.g., SOC 2, ISO 27001) and do not present this document as a formal compliance attestation. The Extension is currently offered in Preview; see Section 9 for current limitations.

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, pipeline run or stage 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.

  • An organization uses one identity at a time, either Setup Automation User or Connect an Entra app. The customer must Disconnect before choosing the other setup. No Azure DevOps passwords and no Personal Access Tokens are collected or stored.
  • Setup Automation User: a work or school account signs in with Microsoft. The Azure DevOps organization does not need to be connected to Microsoft Entra ID. Microsoft personal accounts cannot authorize Azure DevOps and are not supported. Automations run as that signed-in account, not as a service principal. There is no project list. The stored sign-in always includes work-item access and can also include Read pipelines and Run pipelines. One refresh token per organization is stored in Google Cloud Secret Manager. Access tokens minted from it are kept in memory only.
  • Connect an Entra app: the Azure DevOps organization must be connected to Microsoft Entra ID, and the directory used for Connect must be that same directory. When the organization is not connected, this choice stays unavailable. A one-time administrator sign-in adds the Workflow Automation service principal as a Stakeholder user and grants Project Administrators on the selected projects. It is not made a Project Collection Administrator. The administrator token is discarded and is not stored. Runtime tokens are short-lived tokens from the Microsoft Entra client credentials flow and are not persistently stored. Automations run as this service principal, through its Project Administrators membership on the selected projects. That membership covers reading and queuing pipelines there.
  • Inbound Azure DevOps events, including pipeline run and stage events, are authenticated; the receiving endpoint only validates, de-duplicates, matches, and queues work. Work item changes, emails, and pipeline queuing 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, pipeline logs, artifacts, or source; persistent data is limited to connection metadata, automation configuration, operational metadata, compact Execution Logs that expire after about 30 days, and, for Setup Automation User, one refresh token in Google Cloud Secret Manager.

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: Either the Workflow Automation service principal provisioned by Connect an Entra app, or the one work or school account signed in through Setup Automation User. The organization uses one of these identities at a time. Automation actions execute under that 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, pipeline name, run id, result, state, branch, stage name, and run URL when a pipeline is involved, and 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.

Path Mechanism
Extension UI (organization and project hubs) A short-lived Azure DevOps extension token from the signed-in user's browser is used only for the interface. It identifies that user and establishes a session scoped to that user, organization, and project. Declared vso.build is used by the pipeline picker, which shows only definitions that user can already see. vso.wiki and vso.release remain unused, and vso.code is not requested. The token is not stored as an organization credential and is not used to execute automations.
Setup Automation User A Project Collection Administrator sets a contact email, then a work or school account signs in with Microsoft. The Azure DevOps organization does not need to be connected to Microsoft Entra ID. Microsoft personal accounts cannot authorize Azure DevOps and are not supported. The sign-in always includes openid, profile, offline_access, and Azure DevOps delegated vso.work_write. It can also include Read pipelines (vso.build) and Run pipelines (vso.build_execute). Run pipelines includes Read pipelines. A first sign-in starts with Work items and Run pipelines selected. The person can turn Run pipelines off before continuing. An organization that already signed in with only work items must sign in again before a pipeline automation can be saved. Read pipelines is required for a pipeline trigger or Get pipeline work items. Run pipelines is required to queue a run. Code, wiki, and classic Release Management are not part of this sign-in. There is no project list. Automations run as that signed-in account. The callback stores one refresh token per organization in Google Cloud Secret Manager. It is not stored in the application database and is not written to logs. Access tokens are minted from that refresh token when a run needs them and are kept in memory only.
Connect an Entra app and Manage projects The Azure DevOps organization must be connected to Microsoft Entra ID, and the directory used for Connect must be that same directory. When the organization is not connected, this choice stays unavailable. A Project Collection Administrator signs in to Documentero's multi-tenant Microsoft Entra application. That one-time authorization adds the Workflow Automation service principal as a Stakeholder user and grants Project Administrators on the projects the administrator selects. The service principal is not made a Project Collection Administrator. The administrator token is then discarded and is not stored. Manage projects applies only to this identity and uses the same one-time administrator sign-in to add, pause, or resume selected projects. Runtime tokens are short-lived tokens from the Microsoft Entra client credentials flow and are not persistently stored. This identity acts through its Project Administrators membership on the selected projects, which covers reading and queuing pipelines there. It is not granted delegated vso.work_write, vso.build, or vso.build_execute. Automations run as this service principal.
Inbound Service Hooks Each subscription is created with authentication credentials for our receiving endpoint; unauthenticated or incorrectly authenticated requests are rejected.

No Azure DevOps passwords and no Personal Access Tokens are collected or stored. Access tokens are not stored on either path. Only Setup Automation User stores a refresh token, as described above.

2.3 Access Control

  • Organization level: Only Project Collection Administrators can complete Setup Automation User or Connect an Entra app, use Verify or Disconnect, or set the organization contact email. Manage projects applies only to Connect an Entra app.
  • Connect an Entra app: The one-time administrator sign-in 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.
  • Setup Automation User: There is no project list and no Manage projects. Runs are possible in every project that account can already use. The account should be a Project Administrator in each project where automations will run, because turning an automation on creates that project's Service Hook. This path does not add an Azure DevOps user, does not consume a Stakeholder seat for an app, and does not create an Enterprise application.
  • 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 identity in use is permitted to do. For Connect an Entra app, that ceiling is Project Administrators on selected projects, which covers reading and queuing pipelines there. For Setup Automation User, that ceiling is the signed-in work or school account's own permissions, including only the pipeline access included in that sign-in.
  • Project isolation: Automations belong to a single team project. Query results from other projects are dropped, work items linked to a pipeline run in another project are left out, 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, including pipeline run and stage events, only authenticates the request, de-duplicates it, matches enabled automations, and queues work. It does not modify work items, send email, or queue a pipeline.
  • 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 identity in use is not ready, or the organization or automation has been disabled. For Connect an Entra app, a run also fails when the project is not selected.
  • Loop protection: The Service records which automation caused a work item revision, limits cascade depth between automations, and skips self-triggering and cyclic patterns. A cause marker stops a cascade on either identity. For Connect an Entra app, the Service also conservatively skips a change made by the Workflow Automation service principal when the cause marker is missing. For Setup Automation User, the signed-in account's own edits are not skipped merely because the cause marker is missing.
  • 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, 50 work items modified per run, and 20 pipeline runs queued per project per UTC day. The same work item cannot queue the same pipeline again for one hour. Queuing the same pipeline that triggered the current run is refused. 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, email content, or refresh tokens; 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, compact execution records, and, for Setup Automation User, one refresh token in Google Cloud Secret Manager. We do not store copies of your work items, source code, pipeline logs, or artifacts; changes made by automations are written directly to your Azure DevOps organization. Automation definitions may include a pipeline id and name, a stage name, a branch, and template parameter names and values.

  • Connection metadata includes the Microsoft Entra tenant identifier, the identity in use, and connection status. For Connect an Entra app, it also includes the selected-project list. For Setup Automation User, the tenant is the signed-in work or school account's tenant, including when the organization is not connected to Microsoft Entra ID, and there is no selected-project list. Connection metadata 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 Disconnect. Manage projects applies only to Connect an Entra app.

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:

Subprocessor Role Data Types Involved Notes
Google Cloud Platform (incl. Firebase) Hosting, database, serverless compute, task queues, secret and key management, logging Connection and operational metadata, one Setup Automation User refresh token per organization (Google Cloud Secret Manager), automation definitions, and execution logs EU region; encryption in transit and at rest
Brevo Outbound email delivery ("Send customized email" action) Recipient addresses, subject, message body as configured by the customer Used only when an automation includes an email action

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. An organization uses one identity at a time. The customer must Disconnect before choosing the other setup. Customers are responsible for:

  • Connect an Entra app: Ensure the Azure DevOps organization is connected to Microsoft Entra ID and that Connect uses that same directory. When the organization is not connected, this choice stays unavailable. Select only projects where the Workflow Automation service principal should receive Project Administrators membership. It consumes an Azure DevOps Stakeholder seat while it remains under Users. Delete that user to release the seat and, if desired, disable or remove the Enterprise application. A leftover user can block a later Connect.
  • Setup Automation User: The organization does not need to be connected to Microsoft Entra ID. Microsoft personal accounts cannot authorize Azure DevOps and are not supported. The customer is responsible for the permissions of the signed-in work or school account and for choosing an account that should be allowed to change the projects where automations will run.
  • Pipelines: The customer is responsible for which pipelines the identity in use can read or queue, including a pipeline that checks out an external repository through a service connection already saved in Azure DevOps. Queuing that pipeline stays inside Azure DevOps. The Service does not authorize itself to GitHub or Bitbucket, does not start GitHub Actions or Bitbucket Pipelines, and does not read source code or store a repository URL, service-connection secret, or personal access token for those hosts.
  • Controlling who can author automations: Review the project access settings. Project Administrators manage by default and may allow additional groups. Anything the identity in use is allowed to do 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 the access held by the identity in use, and disable or delete Automations that are no longer needed.

For Connect an Entra app, Disconnect clears Documentero's connection state and removes Service Hooks created by Documentero. It does not remove the service-principal user from Azure DevOps Users and does not remove the Enterprise application from Microsoft Entra. For Setup Automation User, Disconnect deletes the refresh token stored for the organization and removes Service Hooks created by Documentero. There is no app user to delete. Stored automations remain but do not run until setup is completed again.

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).
  • Setup Automation User stores one refresh token per organization in Google Cloud Secret Manager. Connect an Entra app does not store a refresh token.
  • Delivery of every Azure DevOps event, including a pipeline run or stage 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.