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.