Security and architecture overview

1. Trust boundary and data flow

Agile Analytics has three distinct data paths. Only one of them crosses Baytek’s backend, and that path carries the licensing, telemetry, and opt-in items itemised in What reaches Baytek above — never work item content.

• Reporting (primary workflow). Customer browser ↔ Azure DevOps REST API. Reads project, team, sprint, work item, and pull request summary data on demand using the signed-in user's ADO session. Renders dashboards client-side. Baytek's backend is not on this path.
• Licensing. Customer browser ↔ ado-analytics.baytekdev.com. Carries activation, validation, revocation, install/heartbeat events, and the telemetry and opt-in items listed above. Payload is limited to organization name, ADO organization ID, extension version, event type, plan, expiry, status, activation tokens, and — where the relevant feature applies — the opaque seat descriptors, allow-listed usage events, and aggregate opt-in payloads described in What reaches Baytek. No work item content.
• Optional integrations. Customer browser → GitHub (api.github.com, for the Copilot Metrics integration) or a webhook endpoint (Microsoft Teams, Slack), only when the org admin has enabled them. Outbound destinations are restricted by Content-Security-Policy. Baytek is not in the request path.

Configuration (workflow mappings, WIP limits, alerts, ACLs, GitHub Copilot Metrics settings, cached license summary) is persisted through Microsoft's Azure DevOps Extension Data Service — hosted by Microsoft, scoped to the customer's ADO organization, not accessible to Baytek.

2. Hosting and infrastructure

• Backend hosting. Google Cloud (Firebase App Hosting on Cloud Run, Cloud SQL for PostgreSQL for persistence), primary region us-central1. Google Cloud maintains SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, and ISO/IEC 27701 attestations.
• Extension distribution. Microsoft Visual Studio Marketplace. The Marketplace signs and serves the extension package; Microsoft hosts the customer’s ADO tenant and the Extension Data Service.
• Marketing / docs site. Same Firebase App Hosting deployment as the licensing backend, served over HTTPS with HSTS.
• Email delivery. Zoho Mail (custom-domain), used for license-key delivery and trial-end reminders. No marketing automation provider holds customer contact data.
• Payment processing. Stripe (PCI DSS Level 1 service provider). Baytek never receives raw card numbers.

3. Encryption

• In transit. TLS 1.2+ on every outbound and inbound connection operated by Baytek; HSTS enforced on ado-analytics.baytekdev.com.
• At rest. Cloud SQL for PostgreSQL encrypts all data at rest with AES-256 by default, using Google-managed keys.
• Secrets management. Backend secrets (Stripe API key, extension signing certificate, email provider credentials, license-signing key) are stored in Google Secret Manager with version pinning per deploy. No secrets in source control, in build artifacts, or in environment files committed to the repository.

4. Authentication and authorization

• Customer → Azure DevOps. The Extension uses the Microsoft-provided VSS SDK. The signed-in ADO user’s session authorizes every request against the customer’s tenant; the Extension does not store or transmit ADO user credentials.
• Extension → Baytek backend. Each licensing request is accompanied by an HMAC-signed application token issued by the Visual Studio Marketplace using the publisher's extension certificate. The backend verifies signature and issuer before doing any work; identity claims in the request body are cross-checked against the token.
• License activation tokens. Bearer credentials issued by the backend after successful activation. Rotated on every successful re-validation (every ~12h of active use). Revoked tokens are retained for 90 days for audit purposes.
• Operator access. Access to the Firebase / Google Cloud project and to Stripe is restricted to named Baytek personnel with multi-factor authentication enforced.

5. Azure DevOps permissions

The Extension declares only read-only Azure DevOps scopes:

• vso.project — project / team / iteration metadata
• vso.work — work items, queries, revision history (read)
• vso.graph — groups and membership (used by Access Control)
• vso.build — build and pipeline run metadata (read; added in v6.26) — powers deployment frequency and the opt-in deploy-linked lead time in DORA Metrics

The Extension cannot modify work items, repositories, pipelines, or permissions. It does not request vso.code, vso.release, or any administrative or write scope. The full scope list is visible on the Marketplace listing prior to install and at every version upgrade.

6. Optional integrations

The GitHub Copilot Metrics integration and webhook notifications are off by default and gated behind an org admin action. When enabled:

• GitHub Copilot Metrics. The GitHub organization name and Personal Access Token are stored in the customer’s ADO Extension Data Service (org-scoped, Microsoft-hosted) as a password-type field and are never logged. Copilot usage and seat data is read directly from the customer’s browser against api.github.com. Baytek never sees the token or the data read with it, and never receives source code, file contents, or Copilot suggestion text.
• Webhook notifications. The Extension posts directly to the configured Microsoft Teams or Slack webhook URL from the customer’s browser. Destination hostnames are restricted to approved provider domains via Content-Security-Policy. Baytek never sees the payload.

7. Data retention

Summary — full table in the Privacy Policy:

• License records: life of account + 7 years (tax / contract).
• Payment notifications: full content, which includes the billing email address, erased after 13 months. A minimal record with no personal data is kept so a re-sent notification is never acted on twice.
• Seat roster: until the seat is unassigned or a deletion request is received.
• Activation tokens: rotated each re-validation; revoked tokens kept 90 days for audit.
• Install / heartbeat events: aggregated; raw events 13 months.
• Usage and error telemetry: raw events 90 days.
• Opt-in trial-contact email: until trial ends or recipient requests deletion (max 90 days post-trial).
• Ask Henry form submissions: kept so we can reply and hold context for follow-ups; deleted on request.
• Opt-in benchmark snapshots: one current snapshot per opted-in organization; deleted immediately on opt-out, and on uninstall via the next aggregation run.
• Opt-in scheduled report content: never stored. Only delivery counters (timestamp, recipient count, payload size) are kept, and deleting a subscription deletes its recipient list.

8. Sub-processors

Summary — full table in the Privacy Policy:

Baytek will notify customers in advance of any addition or replacement of a sub-processor via the changelog on this site and, where required by contract, by email to the billing contact.

9. Vulnerability disclosure

Baytek welcomes coordinated disclosure from security researchers and customer security teams. To report a vulnerability:

• Email support@baytekdev.com with the subject line [SECURITY], or
• Open a private security advisory at github.com/MrHenrySword/agile-analytics-ado/security/advisories.

Baytek will acknowledge receipt within three business days. We follow a 90-day coordinated disclosure window from acknowledgement to public disclosure, extendable by mutual agreement. We do not pursue good-faith researchers operating within scope.

10. Incident response and notification

• For confirmed security incidents that materially affect customer data, Baytek will notify the affected customer's billing contact within 72 hours of confirmation, consistent with the GDPR Article 33 timeline.
• Notifications include scope, known impact, current containment status, and a single point of contact at Baytek.
• Customers running on a Baytek-issued license can request a post-incident report once root cause and remediation are complete.

11. Change management and SDLC

• Source code is version-controlled in Git. Each release is tagged and the corresponding extension package is uploaded to the Visual Studio Marketplace, where Microsoft applies its standard signing and review pipeline before customers can install or auto-upgrade.
• Changes are reviewed before merge; dependency updates are applied through a managed update process and the build is gated by automated linting, type-checking, and unit tests.
• Versioned changelogs accompany every public release on the Marketplace listing and on this site’s What’s New page.
• Patch releases ship via Marketplace auto-rollout (Microsoft-controlled rollout window). Org admins can pin to a specific version through Marketplace governance.

12. Personnel and access

• Baytek operates with a small core team. All personnel with production access are bound by confidentiality obligations.
• Production access (Firebase / Google Cloud, Stripe, Marketplace publisher portal, email provider) is restricted to named individuals and protected by multi-factor authentication.
• Customer data on Baytek-controlled systems (licensing metadata only) is accessed on a least-privilege basis for support, billing, and reconciliation purposes.

13. Available on request

Larger procurement processes typically need more than a public page. Baytek can provide the following on request to a verified prospect or customer:

• Data Processing Addendum (DPA), including Standard Contractual Clauses (SCCs)
• Completed security questionnaire (SIG Lite, CAIQ, or your internal template)
• Sub-processor compliance evidence (Google Cloud, Stripe, Zoho, Microsoft attestation reports as published)
• Architecture diagram of the licensing backend and data flow
• Internal control documentation: the data-flow document, the data-inventory and retention table, and the logging and redaction policy
• Vendor onboarding form completion
• Insurance certificate (on request from active or pending paid customers)

Send requests to support@baytekdev.com with subject line [SECURITY-REVIEW] and a brief description of your evaluation context. A Baytek principal will respond directly.

14. Out of scope

Baytek does not currently hold its own SOC 2 or ISO 27001 attestation for the licensing backend. The backend relies on the underlying compliance posture of Google Cloud, Stripe, Microsoft, and Zoho (listed in section 8). If formal first-party attestation is a hard requirement for your procurement process, please raise that early so we can scope an alternative path — typically a customer-supplied questionnaire backed by sub-processor evidence and the DPA.

The control documentation behind this page — the data-flow document, the data-inventory and retention table, and the logging and redaction policy — is maintained internally and available on request under NDA (section 13). It is preparation material for a future audit. It is not an audit report, an attestation, or a certification, and this page should not be read as claiming one.

15. Security boundary and accepted risks

Azure DevOps Access Control (roles, view permissions, group locks) and the Extension's audit log are operational controls, configured by the org admin and stored in the customer's own Azure DevOps org-scoped storage. They are not an enforced security boundary maintained by Baytek. At every point in time, a user's actual ability to read Azure DevOps data is governed by that user's own Azure DevOps permissions — set and enforced by Microsoft, not by the Extension. Access Control shapes what the Extension's UI shows a given user; it does not, and cannot, grant or revoke access to the underlying Azure DevOps organization.

Two accepted risks follow directly from that boundary:

16. Product roadmap

Capabilities that larger security teams often ask for and that are on the roadmap, not shipped today:

• SCIM provisioning for automated user lifecycle management
• SIEM log export of extension activity and admin actions
• Scheduler-bounded seat revocation (revoking a seat immediately rather than at the next license re-validation)

Single sign-on is not on this list because it is not a gap: the Extension only ever runs as the signed-in Azure DevOps user, inside an Azure DevOps-hosted iframe. Sign-in — and any SSO policy applied to it — is inherited from the customer's own Azure DevOps / Microsoft Entra ID configuration by architecture. There is no separate Baytek-side login to secure and no separate SSO integration to add.

17. Contact

• Security questions and procurement: support@baytekdev.com
• Privacy / data-subject requests: support@baytekdev.com (see Privacy Policy § 12)
• Company: Baytek Software (publisher Baytek on the Visual Studio Marketplace)