This is the version string recorded in the acceptance record for every consent granted to the SCOUTz Microsoft 365 Review application. If the version shown here does not match the version shown on the consent page you used, the version recorded in your acceptance record governs, and you may request a copy of it from privacy@scoutzsecurity.io.
Read with: the Terms of Use and the Privacy Statement. Where this Addendum and those documents differ on the processing of personal data, this Addendum governs.
1. Parties, scope and acceptance
1.1 Parties. This Data Processing Addendum ("Addendum") is entered into between SCOUTz LLC, an Arizona limited liability company ("SCOUTz", "Processor"), and the managed service provider that operates a SCOUTz account and runs a review ("Provider", "Controller"). It forms part of the agreement under which the Provider uses the SCOUTz platform (the "Agreement").
1.2 Acceptance. This Addendum is accepted electronically on the SCOUTz consent page before a tenant is sent to Microsoft to grant access. Acceptance is recorded in an immutable audit record carrying the accepting identity, the timestamp and the version string \2026-06-oauth-readonly-v1\. No review can begin until that record exists. Continuing to operate a SCOUTz account constitutes acceptance by the Provider.
1.3 Customer tenants. The organisation whose Microsoft 365 tenant is reviewed (the "Customer") is not a party to this Addendum. The Provider warrants that it has the authority, from the Customer and under the Provider's own agreement with the Customer, to instruct SCOUTz to carry out the review. Where the Customer is the controller of the personal data under applicable law and the Provider is that Customer's processor, this Addendum takes effect as the sub-processing terms between the Provider and SCOUTz, and the obligations SCOUTz owes the Provider here are owed on the same terms in respect of that Customer's data.
1.4 Publisher of record. The application is registered in Microsoft's directory under AEGITz LLC, an affiliate of SCOUTz LLC, which appears as the verified publisher on Microsoft's consent screen. SCOUTz LLC operates the platform, is the processor of the data described here, and is the party bound by this Addendum. When the registration moves to SCOUTz LLC, a new consent will be requested and this Addendum will be re-issued under a new version string.
1.5 Version changes. SCOUTz will not process personal data under a materially different scope, purpose, retention period or sub-processor arrangement without publishing a new version of this Addendum at this URL and requiring a new acceptance. A new acceptance is required before the next review runs; reviews already completed remain governed by the version recorded against them.
2. Definitions
"Personal data", "processing", "controller", "processor", "sub-processor", "data subject" and "personal data breach" have the meanings given in the EU General Data Protection Regulation (Regulation (EU) 2016/679, "GDPR"), and are read to include the equivalent concepts in the UK GDPR, the California Consumer Privacy Act as amended ("CCPA") and other Data Protection Laws.
"Data Protection Laws" means all laws applicable to SCOUTz's processing of personal data under this Addendum, including the GDPR, the UK GDPR, the Swiss FADP, the CCPA and US state privacy laws.
"Tenant Data" means the configuration and metadata read from a Customer's Microsoft 365 tenant through the Microsoft Graph API under a consent granted to the SCOUTz application, and the findings derived from it.
"Review" means one execution of a SCOUTz security review against a Customer tenant.
"Findings" means the machine-readable result set a Review produces and the reports rendered from it.
"Audit Records" means the append-only platform records described in section 10.4.
3. Roles
3.1 As between the Provider and SCOUTz, the Provider is the controller and SCOUTz is the processor of Tenant Data.
3.2 SCOUTz processes Tenant Data only on the Provider's documented instructions. The instructions are: this Addendum, the Agreement, the scope granted on the Microsoft consent screen, and the Provider's use of the platform's own controls (starting a Review, pinning a baseline, issuing a report, deleting data).
3.3 SCOUTz is a "service provider" for the purposes of the CCPA. SCOUTz does not sell or share Tenant Data, does not retain, use or disclose it for any purpose other than performing the Review and the platform services, and does not combine it with personal data received from any other source except as permitted by the CCPA for a service provider.
3.4 Unlawful instruction. SCOUTz will tell the Provider without undue delay if, in its opinion, an instruction infringes Data Protection Laws, and may suspend that instruction until it is withdrawn or amended.
4. Subject matter, duration, nature and purpose
4.1 Subject matter. Read-only assessment of the security configuration of a Microsoft 365 tenant.
4.2 Nature and purpose. SCOUTz reads configuration and metadata from the Customer tenant through the Microsoft Graph API, evaluates it against SCOUTz's checks, and produces Findings and reports for the Provider to use in advising the Customer. SCOUTz creates, modifies and deletes nothing in the Customer tenant.
4.3 Duration. For the term of the Agreement, and for each Review, for the retention periods in section 10.
4.4 Categories of data subject and personal data. Set out in Annex I.
4.5 No special category data is requested. SCOUTz does not request, and the application cannot obtain, the content of mail, documents, files, chats, meetings or Copilot interactions, nor passwords or authentication secrets. Special category data may nevertheless appear incidentally in a free-text directory attribute a Customer has chosen to populate (for example a job title or department). SCOUTz does not use such data for any purpose beyond rendering the directory record from which it was read.
5. Read-only and least-privilege processing
5.1 Read-only permissions only. The application holds Microsoft Graph permissions classified as read. SCOUTz will not add a write permission to the registration.
5.2 Fail-closed verification. Before any read, SCOUTz inspects the permission claims in the access token Microsoft actually issued. If any granted permission is a write permission, the connection is rejected and no data is read. This is enforced in code, on every token, and does not depend on the permission list configured in the directory.
5.3 Content refusal. SCOUTz maintains a registry classifying every permission the application may request as configuration or content. A permission classified as content is refused. A grant carrying one causes the connection to be rejected rather than narrowed.
5.4 No write-back, no remediation. SCOUTz does not act on a Customer tenant. Remediation advice is delivered as text for a human to act on.
6. Credentials and tokens
6.1 No persisted tenant credential. For a tenant consented under this version, SCOUTz stores no Microsoft access token and no Microsoft refresh token. Access is obtained per Review by a client-credentials exchange against the consent standing in the Customer's own tenant, held in memory for the duration of the Review, and discarded. There is no stored credential that could be stolen, replayed or used outside a Review.
6.2 Retired delegated path. The earlier connection path that stored an encrypted delegated token is retired: its routes refuse all requests. Any legacy record predating this version remains encrypted under envelope encryption as described in Annex II and is not used by the current rail.
6.3 Effect of revocation. Because SCOUTz holds no credential, removing the application's consent in the Customer's Microsoft Entra admin centre ends SCOUTz's ability to read from that tenant at the next attempt. No further reads occur. Existing Findings are governed by section 10.
7. Confidentiality and personnel
7.1 SCOUTz ensures that persons authorised to process Tenant Data are bound by an obligation of confidentiality that survives the end of their engagement.
7.2 Least privilege by default. SCOUTz platform personnel do not have standing access to a Provider's or Customer's Findings. Access to Provider or Customer data by SCOUTz personnel requires an explicit, time-limited grant recording the operator's identity, the reason, the scope and the expiry. The grant and every access made under it are written to an append-only, hash-chained ledger that is visible to the owning Provider through the platform. There is no path for SCOUTz personnel to read Provider or Customer data without producing that record.
8. Security measures
SCOUTz implements the technical and organisational measures described in Annex II. SCOUTz may update them, provided the level of security is not reduced.
9. Sub-processors
9.1 General authorisation. The Provider authorises SCOUTz to engage the sub-processors listed in Annex III.
9.2 Terms. SCOUTz imposes on each sub-processor data protection obligations no less protective than those in this Addendum, and remains fully liable to the Provider for each sub-processor's performance.
9.3 Change notice. SCOUTz will give the Provider at least thirty (30) days' notice, by email to the Provider's account contact and by updating Annex III at this URL, before adding or replacing a sub-processor that processes Tenant Data. The Provider may object on reasonable data protection grounds within that period; if the objection cannot be resolved, the Provider may terminate the affected service without penalty for the remainder of its term.
9.4 Scope boundary. The sub-processors that support the public-domain review receive a domain name or a public IP address only. They do not receive Tenant Data. Annex III states this per entry.
10. Retention and deletion
10.1 Findings: thirty days. Findings are retained for thirty (30) days from the completion of the Review and are then deleted. The period is enforced twice: a read past the expiry returns as though no Findings exist, so expired Findings are invisible even before deletion runs; and a scheduled job clears the stored Findings for expired Reviews.
10.2 Pinned baselines. Where the Provider pins a Review as a comparison baseline, the Findings of that Review are retained until the Provider unpins or deletes it. Pinning is a Provider action, taken with the Customer's knowledge, and is recorded.
10.3 Issued reports. A report the Provider has generated or exported (PDF or hosted report) is a point-in-time copy the Provider holds and distributes. Retention under 10.1 governs live, queryable Findings inside the platform; it does not retrieve a copy already in the Provider's or Customer's hands. The Provider is responsible for the copies it issues.
10.4 Audit Records are permanent. Records that a Review was run, that consent was granted, that this Addendum was accepted at a stated version, that consent was revoked, and that an operator opened a break-glass grant, are written to an append-only log that cannot be updated or deleted by anyone, including SCOUTz personnel and including on deletion of the Provider's account. This is a deliberate accountability measure: the record that data was accessed must outlive the data. These records contain the acting identity (an account identifier and email address), the source IP address, the action, the outcome and a resource identifier. They do not contain Tenant Data or Findings. SCOUTz relies on its legitimate interest, and the Provider's and Customer's interest, in a tamper-evident record of access to security data. A data subject may ask, at privacy@scoutzsecurity.io, what Audit Records name them and why.
10.5 Deletion on request. On the Provider's written request, SCOUTz will delete a Review and its Findings ahead of the thirty-day expiry. On termination of the Agreement, SCOUTz will delete the Provider's account data, subject to 10.4.
10.6 Return of data. Before deletion, the Provider may export its Findings through the platform. SCOUTz does not otherwise hold Tenant Data in a form requiring return.
11. Assisting the Provider
11.1 Data subject requests. Taking into account the nature of the processing, SCOUTz will assist the Provider by appropriate technical and organisational measures, insofar as possible, in responding to requests to exercise data subject rights. Because SCOUTz holds no independent relationship with the data subjects and holds their data only for thirty days, assistance will ordinarily consist of identifying what was read, locating the records concerned and deleting them.
11.2 Coverage record. Every Review carries a record of each area read, not read, or refused, and why. SCOUTz will provide that record on request. It is the authoritative answer to "what did you read".
11.3 Impact assessments. SCOUTz will provide the Provider with reasonable assistance with data protection impact assessments and prior consultations, using the information in this Addendum and its annexes in the first instance.
12. Personal data breach
12.1 SCOUTz will notify the Provider without undue delay, and in any event within seventy-two (72) hours, after becoming aware of a personal data breach affecting Tenant Data.
12.2 The notice will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where the information is not all available at once, it will be provided in phases without undue further delay.
12.3 SCOUTz will not make any public statement identifying a Provider or a Customer in connection with a breach without the Provider's prior written consent, except where required by law.
13. Audits
13.1 SCOUTz will make available to the Provider the information necessary to demonstrate compliance with Article 28 GDPR, and will allow for and contribute to audits, including inspections, conducted by the Provider or an auditor it mandates.
13.2 Audits are conducted no more than once in any twelve-month period, except following a personal data breach or where required by a supervisory authority, on at least thirty (30) days' notice, during business hours, subject to confidentiality, and in a manner that does not compromise the security of other customers' data.
13.3 SCOUTz will first offer its then-current security documentation, the coverage records for the Reviews in question, and written answers. An on-site or system inspection proceeds where those do not reasonably satisfy the Provider's obligations.
14. International transfers
14.1 Tenant Data is processed in the United States. SCOUTz does not transfer Tenant Data outside the United States except through the sub-processors in Annex III acting on SCOUTz's instructions.
14.2 Where the Provider or a Customer is established in the European Economic Area, the United Kingdom or Switzerland, and a transfer of personal data to SCOUTz is a restricted transfer, the Standard Contractual Clauses approved by the European Commission in Implementing Decision (EU) 2021/914 are incorporated into this Addendum by reference and apply to that transfer:
- Module Two (controller to processor) where the Provider is a controller;
- Module Three (processor to sub-processor) where the Provider is a processor of the Customer.
For those clauses: the Provider is the data exporter and SCOUTz is the data importer; the optional docking clause applies; the supervisory authority is that of the exporter's member state; clause 17 is governed by Irish law and clause 18(b) designates the courts of Ireland; Annexes I, II and III to those clauses are Annexes I, II and III below.
14.3 For UK transfers, the UK International Data Transfer Addendum (version B1.0) to the Standard Contractual Clauses is incorporated, with the tables completed from the information in this Addendum and its annexes. For Swiss transfers, references to the GDPR are read as references to the FADP and the Swiss Federal Data Protection and Information Commissioner is the competent authority.
14.4 Government access. SCOUTz will, to the extent legally permitted, notify the Provider of any legally binding request from a public authority for Tenant Data, will challenge a request it considers unlawful, and will disclose only the minimum the request compels.
15. General
15.1 Term. This Addendum takes effect on acceptance and continues while SCOUTz processes Tenant Data for the Provider. Sections 7, 10.4, 12 and 15 survive.
15.2 Liability. Each party's liability under this Addendum is subject to the limitations and exclusions of liability in the Agreement.
15.3 Precedence. In the event of a conflict, this Addendum prevails over the Agreement, the Terms of Use and the Privacy Statement in respect of the processing of personal data.
15.4 Governing law. Except where section 14 requires otherwise for the Standard Contractual Clauses, this Addendum is governed by the laws of the State of Arizona, and the parties submit to the state and federal courts located in Arizona.
15.5 Severability. If a provision is held unenforceable, the remainder continues in effect.
15.6 Contact. privacy@scoutzsecurity.io. SCOUTz LLC, c/o Republic Registered Agent LLC, 3101 N. Central Ave, Ste 183, Phoenix, AZ 85012, United States.
Annex I — Description of the processing
Data exporter. The Provider (the managed service provider operating the SCOUTz account), acting for the Customer whose tenant is reviewed.
Data importer. SCOUTz LLC, c/o Republic Registered Agent LLC, 3101 N. Central Ave, Ste 183, Phoenix, AZ 85012, United States. Contact: privacy@scoutzsecurity.io. Activities: read-only security review of Microsoft 365 tenant configuration. Role: processor.
Categories of data subject
- Users of the Customer's Microsoft 365 tenant, including employees, contractors and guest accounts.
- Administrators of the Customer's tenant, including the administrator who grants consent.
- Staff of the Provider who use the SCOUTz portal.
Categories of personal data
| Category | Examples |
|---|---|
| Account identity | Display name, user principal name, email address, account enabled or disabled, creation date |
| Employment attributes | Job title, department, office location, manager, as populated in the directory |
| Access and privilege | Directory role assignments, group and role membership, administrative role eligibility and activation |
| Authentication posture | Which authentication methods are registered, last sign-in date, sign-in risk state as reported by Microsoft |
| Licensing | Assigned licences and service plans |
| Device association | Device records and their join type, operating system build and compliance state, and the registered owner |
| Application grants | Enterprise applications, the permissions granted to them, and the identity that granted them |
| Consent record | The granting administrator's identity and email address, the scopes granted, the acceptance of this Addendum and its version |
| Provider portal accounts | Name, email address, role, session and access records |
| Access records | Acting identity, email address, source IP address, action, outcome, timestamp |
Categories of personal data NOT processed. Content of mail, documents, files, chats, meetings or Copilot interactions. Passwords, password hashes, authentication secrets, recovery codes. Payment card data. SCOUTz does not request the Microsoft Graph permissions that would allow it to read these, and refuses a grant that carries one.
Frequency. Point in time, on each Review the Provider runs. Reviews are run on demand or on a schedule the Provider sets.
Duration of retention. As in section 10: Findings thirty days, or until unpinned where pinned as a baseline; Audit Records permanent.
Purpose. Producing a read-only security review for the Provider to use in advising the Customer. No other purpose. No profiling, no automated decision-making producing legal or similarly significant effects, no training of machine learning models on Tenant Data.
Annex II — Technical and organisational measures
Tenant isolation. Every tenant-owned table in the platform database is under PostgreSQL row-level security in FORCE mode, keyed to the owning organisation's position in the organisation hierarchy. The application connects as a non-superuser role for which those policies cannot be bypassed, and the isolating context is set per transaction. A query that arrives without that context reads nothing rather than reading everything.
Encryption in transit. TLS for all connections to the platform, to the Microsoft Graph API, and between the platform and its database.
Encryption at rest. Stored secrets use envelope encryption: a per-secret 256-bit data encryption key under AES-256-GCM, itself wrapped by a customer master key held by the configured key provider. The database stores only ciphertext and the wrapped key, never a plaintext key and never one shared key across tenants. Disk-level encryption is provided by the hosting platform.
No stored tenant credential. As in section 6. Access tokens exist only in process memory for the life of a Review.
Read-only enforcement. As in section 5: permission claims are verified on every acquired token and a write or content permission causes rejection before any read.
Secrets management. Secrets are supplied by environment configuration, never committed to source control and never written to disk by the application. The service refuses to start in production unless its required secrets, including the encryption key material, are present and valid. Log output is passed through redaction that strips token, key, credential and password values.
Access control. Authentication to the portal is by single sign-on or passkey. Authorisation is role and scope based, evaluated per route. Platform personnel access to Provider or Customer data requires a recorded, time-limited break-glass grant as described in section 7.2.
Logging and accountability. Every consent grant, revocation, Review, report issue, administrative action and denied access attempt is written to an append-only log protected by database triggers that reject updates and deletes, with the application role's update and delete rights revoked. A cross-tenant or denied attempt is recorded even though it is refused.
Data minimisation. The application requests configuration permissions only. Client-facing reports omit account identifiers by default; the Provider chooses whether to include them in a report it issues.
Availability and resilience. Managed PostgreSQL with automated backups and point-in-time recovery provided by the hosting platform. Backups inherit the encryption above.
Development controls. Changes are reviewed and merged through a pipeline that runs type checks, unit and integration tests, tenant-isolation tests and a route authorisation guard. Migrations are applied before the restricted application role's grants are re-applied, so a new table does not silently inherit broader rights.
Testing. Tenant isolation, read-only enforcement, content refusal, retention expiry and audit immutability are each covered by automated tests that run on every change.
Annex III — Sub-processors
A. Sub-processors that process Tenant Data
| Sub-processor | Role | Location | Data |
|---|---|---|---|
| Microsoft Corporation | Source of Tenant Data via the Microsoft Graph API | United States | The configuration and metadata described in Annex I, read from the Customer's own tenant |
| Railway Corporation | Application and database hosting | United States | All platform data, including Findings, at rest and in transit |
B. Services used by the public-domain review only
These services receive a domain name or a public IP address. They do not receive Tenant Data, Findings, account identifiers or any personal data from a Microsoft 365 tenant.
| Service | Purpose |
|---|---|
| Shodan | Internet-exposure lookup for a public IP or host |
| Have I Been Pwned | Breach exposure lookup for a domain |
| Spamhaus | Mail reputation lookup for a domain or IP |
| FIRST (EPSS) | Exploit prediction scores for published vulnerabilities |
| CISA | Known Exploited Vulnerabilities catalogue |
| Apollo.io | Company firmographic enrichment from a domain |
| Brave Search | Public web search for a domain |
| Google Safe Browsing | Malicious-site status for a domain |
| Sectigo (crt.sh) | Public certificate transparency records for a domain |
| RDAP registries | Public domain registration records |
The current list is maintained at scoutzsecurity.io/legal/dpa. Changes are notified under section 9.3.
SCOUTz Data Processing Addendum, version \`2026-06-oauth-readonly-v1\`. SCOUTz LLC, Arizona, United States.