Entra privacy statement: configure a usable tenant URL

What an Entra privacy statement provides

An Entra privacy statement is an organization-level link to the document explaining how your organization handles people's data. Configure it with a maintained privacy contact so employees and external guests can find the information intended for them. The useful outcome is a readable, relevant document and a reachable owner, rather than a populated field that nobody has tested.

Microsoft's privacy information setup guide covers both the global privacy contact and the statement URL. It describes their use for internal employees and external guests, including the B2B invitation experience. When neither is supplied, Learn illustrates a Review Permissions message indicating that the organization has not provided review links. Treat that presentation as a reason to inspect the actual guest journey, not as a claim that invitations are blocked.

Decide who owns the document before changing the tenant. A partner receiving an invitation may need information that differs from an employee's internal handbook. Ask the responsible privacy and legal reviewers to confirm the document's scope and language. A missing tenant URL is a configuration observation; it does not establish a universal legal violation or determine which obligations apply to your organization.

How privacy information differs from document acceptance

The Graph privacyProfile resource separates contactEmail from statementUrl. Both properties are optional in the schema. The email identifies the privacy statement contact, while the URL points to the organization's statement. An optional API field can still be useful for your operational requirements; optionality does not decide whether your organization needs the information.

Learn defines a statement URL beginning with HTTP or HTTPS. For a new deployment, choose a stable HTTPS destination and test it from the populations that will read it. A document available only after employee authentication may be unsuitable for a newly invited external collaborator. Avoid assuming that an administrator's ability to open the page proves a guest can reach it.

Publishing this link supplies information. It does not configure a Conditional Access grant requiring acceptance, create an acceptance record, or prove that someone read the text. The Entra terms of use and Conditional Access acceptance guide covers that separate requirement: an approved agreement and an enforcing policy must be connected when acceptance is the intended access condition.

Detection: verify configuration, destination, and guest presentation

Read the organization profile with appropriate Graph access

First confirm the tenant you are reviewing. In the Entra admin center, inspect Entra ID > Overview > Properties, including the global privacy contact and privacy statement URL. Preserve the observation time and the exact values so you can compare the portal with an independent API read.

Microsoft's List organization documentation supports GET /organization and the $select query parameter. Use this request to retrieve the profile:

GET https://graph.microsoft.com/v1.0/organization?$select=privacyProfile
Authorization: Bearer {token}

This is a request template for your authorized client, not a query executed against a customer tenant for this article. Inspect both privacyProfile.contactEmail and privacyProfile.statementUrl in the returned organization. Keep the response and collection errors with the review record; do not substitute a portal screenshot for an API result when investigating collection behavior.

The organization read documentation lists Organization.Read.All for application access and supports it for delegated work or school access. It specifically warns that User.Read exposes only id, displayName, and verifiedDomains, with other properties returning null. Use at least Organization.Read.All to read the privacy profile, and check the supported role requirements for a delegated client. A successful response with insufficient property visibility must not become evidence of absence.

Test the destination independently of the Graph probe

A completed organization query and an available privacy document are different observations. Record the exact returned URL, then issue an independent HTTP request to that destination. For an authorized public statement, a diagnostic request can look like this:

curl --location --silent --show-error --output privacy-statement.html --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' 'https://example.org/privacy'

Replace the example with the approved destination. Review the final response and saved body, rather than accepting the status code alone. A successful response might contain a generic landing page, a sign-in form, or an unrelated document. Check redirects, the organization named in the text, and whether the page explains the intended data handling. Inspect it in a browser as well, including navigation and readability.

Test access from an employee context and an external context representative of the invitation flow. If the destination requires authentication, determine whether that requirement is intentional and workable before the guest joins. Record an unavailable page, unexpected redirect, stale document, or unsuitable language as a destination issue even when the tenant field is populated. Separately confirm that the listed contact is monitored and assigned to a responsible owner.

Exercise a representative B2B invitation

Use an approved test invitation and observe the guest's actual experience. Verify the organization shown, the privacy information offered, the destination reached when the link is followed, and the contact presented. Record the guest context and the journey used, since an existing guest returning to an application does not reproduce a new invitation experience.

The guest Conditional Access and external collaboration review helps frame the intended external population and its access settings. Keep that access review alongside this information check. A working privacy link does not establish that guest invitations, policy assignments, application access, or lifecycle settings meet your requirements.

Remediation: publish and maintain a usable tenant URL

1. Assign the document and contact owners

Identify the reviewer responsible for the statement and the team responsible for answering privacy questions. Agree on the intended employee and guest audiences, languages, and publication location. Give the tenant administrator approved values to enter. Do not let the administrator invent the privacy text simply to remove an audit finding.

Use a contact address with an explicit handover process when staff change. Decide who checks incoming messages and who handles a broken document link. Record where the approved document is maintained and how changes to its scope receive review. These are operational decisions to make locally, not legal conclusions drawn from the tenant setting.

2. Validate the destination before configuring Entra

Publish the approved statement at a stable URL. Verify that the intended internal and external readers can reach the relevant content, and that supported languages remain accessible from that destination. Keep the page understandable without requiring a guest to navigate an employee-only document library.

Record the destination test separately from the tenant change. If your publishing system redirects the link, review the final target and ensure future redirects remain under the document owner's control. A permanent organizational URL is easier to maintain than a link tied to a temporary campaign, a personal workspace, or an expiring sharing token.

3. Enter the values in Properties

Follow Learn's Properties procedure: sign in as at least a Billing Administrator, browse to Entra ID > Overview > Properties, enter Global privacy contact and Privacy statement URL, and select Accept as documented. That portal action saves the organization's information; it is not a guest's acceptance of your document.

If your approved change process uses Graph instead, Update organization documents PATCH /organization/{id} with Organization.ReadWrite.All for delegated work or school and application access. Use the verified organization ID and inspect delegated role requirements before writing. Send the intended profile values without changing unrelated organization properties:

PATCH https://graph.microsoft.com/v1.0/organization/{organization-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "privacyProfile": {
    "contactEmail": "[email protected]",
    "statementUrl": "https://example.org/privacy"
  }
}

The example is a documented request pattern with placeholder values, not an executed tenant change. Keep writing permissions separate from the read-only review client. A successful update response is a starting point for verification, not the final evidence that people can use the document.

4. Re-read the profile and repeat the guest test

Repeat the selected organization GET and compare both properties with the approved values. Recheck the destination independently, then repeat the representative invitation review. Preserve failures as well as successful observations. If the profile differs, investigate the tenant context and update result before repeating a write.

If the information is configured but the tested guest journey does not show it as expected, retain the API evidence and the observed presentation as separate facts. Investigate that journey instead of repeatedly replacing a correct URL. Avoid adding a terms of use requirement as an improvised fix for missing privacy information; acceptance needs its own approved purpose and scope.

5. Maintain languages, links, and ownership

Review the statement when data handling, document hosting, guest populations, or contact ownership changes. Update translations together with the approved source document. After a hosting migration, repeat the HTTP and browser checks even if the tenant URL remains unchanged. After a contact handover, verify that the address still reaches the responsible team.

Keep the approved values, Graph readback, destination checks, guest observations, and owner decisions together. This makes it possible to distinguish configuration drift from a publishing outage or a change in the invitation experience. Define a review cadence appropriate to your organization rather than treating the first successful save as permanent evidence.

How EtcSec Detects This

The etc-collector AZ_NO_PRIVACY_STATEMENT detector reads AzurePrivacyStatementProbed and AzurePrivacyStatementURL. Its Detect() implementation has three branches:

Count 1 is the finding count, not a count of affected guests. Not probed is not absent, and the Info branch is not a compliance verdict. Resolve collection failures before drawing a configuration conclusion.

The provider issues GET /organization?$select=privacyProfile, reads the first organization's statementUrl, and returns an empty string without error when the organization list is empty or the profile is absent. Request and decoding errors are returned separately. An unexpected empty inventory therefore deserves investigation alongside permissions and tenant context.

Neither the provider nor this detector trims the string: whitespace is nonempty and passes the comparison. Neither requests the statement's URL, verifies the contact, or reviews document content or languages. The provider does not collect contactEmail for this check. A nonempty URL can remove this finding while the destination is unavailable or unsuitable. Pair this narrow configuration result with the independent destination and invitation tests above, and retain the document owner's suitability decision.