Documentation is a claim until the system is read against it

A configuration standard, approved when external sharing was turned off for the organisation, says that SharePoint content is not shared outside it. Once a year a reviewer opens the SharePoint admin centre, finds the organisation-level setting at Only people in your organization, and signs the line. In the eighth month the organisation-level setting is relaxed for a partner project. For each site that allowed sharing before the organisation turned it off, Microsoft documents what follows: "the site sharing setting returns to what it was before and the shared links resume working" (change the sharing settings for a site). The last review was true on the day it was signed, and the next one is four months away.

Nothing malfunctioned. The standard recorded a decision, the tenant kept its own state, and the review read only the part of that state the standard happened to name. A document is a control only while it is bound to the system it describes: an owner, a documented way to read the system's actual state, a comparison of that reading with the document, and a date to read it again. Without them, it records an intention the system is free to leave behind.

This analysis is for whoever writes, keeps or relies on configuration documents for Microsoft 365 and Azure, including the evidence attached to compliance tools. NIST SP 800-53 Rev. 5 and Microsoft's documentation were checked on 7 November 2026. No tenant was accessed; the PowerShell below is illustrative and was not run.

What the control catalogue asks of a document

NIST SP 800-53 Rev. 5, quoted here from Release 5.2.0, never treats a document as finished. CM-2 begins "Develop, document, and maintain under configuration control, a current baseline configuration of the system", and has it reviewed and updated at a frequency the organisation sets, when circumstances require, and "When system components are installed or upgraded". Its discussion adds: "Maintaining baseline configurations requires creating new baselines as organizational systems change over time." CM-8 asks for a component inventory that reflects the whole system accurately, reviewed on a schedule and, in its first enhancement, updated with every installation, removal and system update. CM-2(2) and CM-8(2) ask for automated mechanisms to maintain the "currency, completeness, accuracy, and availability" of both.

The catalogue is just as plain that writing a thing down is not the control. "Simply restating controls does not constitute an organizational policy or procedure," says the discussion of CM-1; the control itself designates an official to manage the policy and its procedures (SP 800-53, above). CA-2 assesses whether controls are "implemented correctly, operating as intended, and producing the desired outcome", and its discussion says organisations "conduct assessments on the implemented controls as documented in security and privacy plans". The document is what the system is checked against, not evidence that the check passed. Even SA-5, on administrator documentation, asks organisations to consider "specific measures to determine the quality and completeness of the content provided".

What the catalogue leaves open: every frequency is an assignment the organisation fills in, and nothing in it says how a SharePoint setting is read. Mapping the controls to a tenant is the organisation's work; in this article it is ours.

What Microsoft's governance guidance adds

The Cloud Adoption Framework writes the reading into the policy. Its guidance on documenting cloud governance policies says policies "are meant to be authoritative references" and asks each statement to "Name the tool required for enforcement so you know where to monitor compliance". Its example policies each carry a Monitoring entry, from Azure Policy to "Manual audit (monthly)". The guidance on monitoring cloud compliance repeats it, "If there's a manual approach, list the audit frequency", and then distrusts its own instruments: "Even with automated monitoring, conduct periodic manual reviews and audits to validate compliance monitoring processes and ensure that automation tools are functioning correctly." Policies are reviewed on a schedule and after events, "such as a failed governance policy, technology change, or regulatory compliance change" (documenting policies, above).

The example table has no column for an owner or for the last reading. The Well-Architected Framework's guidance on standardising operations supplies a name and a date: "require scheduled reviews as part of the team's operational cadence. Include authorship and review dates, and highlight changes in procedures."

For Azure resources deployed from code, the template is the document, and the CAF administration guidance makes the comparison routine: "Regularly compare the live environment with your desired configuration to detect drift" It runs both ways: when a change has to be made outside code, the instruction is to "Promptly update IaC files if manual adjustments are necessary to preserve the accuracy of your desired configuration." Our reading: a template that is not compared with the live environment is documentation like any other.

Four bindings, and who asks for them

Holding all four on one line, for every control, is our recommendation below.

Compliance Manager keeps the recorded and the read apart

Microsoft Purview Compliance Manager makes the distinction a field. Each improvement action shows a testing type, Manual or Automatic (improvement actions). On a manual action, "You set the necessary implementation and test status states, and upload any evidence files on the Evidence tab", and Passed means "implementation has been verified by an assessor". On an automatic one, Compliance Manager "automatically identifies settings in your Microsoft 365 environment and your multicloud environment", and the test status cannot be edited. Automatic testing even has a word for a control it could not read: Could not be detected, "couldn't detect a test status; will be automatically checked again" (same source).

Evidence changes which kind an action is: "When you add your own testing data or evidence into an improvement action, automatic testing is turned off for that action to ensure that Compliance Manager doesn't overwrite any of your data" (setup). Our reading: attaching a document can turn a reading back into a recorded statement, and the testing type is the only field that says so. Both kinds earn the action its points (improvement actions, above), the dashboard turns points into a percentage (setup, above), and Microsoft's scoring page warns that the tool's recommendations "should not be interpreted as a guarantee of compliance". We would carry each action's test status, testing type and test date into a review, and leave the percentage out: a total cannot say which of its parts were read.

Three settings where the document and the tenant can disagree

Microsoft documents both sides of each: the setting, and how to read what the tenant holds.

Sharing: the organisation's value, and each site's two

"If a site's external sharing option and the organization-level sharing option don't match, the most restrictive value always applies" (external sharing overview). The site keeps its own value underneath, which is why it can come back. The Get-SPOSite reference names the two values: SiteDefinedSharingCapability "Returns the stored value of the site policy", and SharingCapability "Returns the effective access level, which is the site policy and the tenant policy combined". A listing is not a reading: with -Limit or -Filter, SharingCapability is among the properties that "will not be populated and may contain a default value" (same source).

A standard that says sharing is off is bound to the tenant when its reading takes the organisation's value and, for every site, the effective and the stored ones:

# Illustrative and read-only; not run for this article.
# The organisation's level, through Microsoft Graph PowerShell:
(Get-MgAdminSharepointSetting).SharingCapability

# Each site by its address, in the SharePoint Online Management Shell:
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/projects |
    Select-Object Url, SharingCapability, SiteDefinedSharingCapability

The first line reads Graph's sharepointSettings, whose sharingCapability is the "Sharing capability for the tenant"; a delegated call needs Global Reader or SharePoint Administrator (get settings). The second needs more: "You need to be a SharePoint Online administrator and be a site collection administrator to run the cmdlet" (Get-SPOSite, above). Our reading: in the opening case the stored values were the warning, and a review that read only the organisation's level, or only each site's effective value, could not see them. Who can run each reading belongs in the record beside it.

Group creation: a directory object that may not exist

A sentence saying that only one group's members create Microsoft 365 groups describes a directory object. "Initially, Microsoft Entra ID assigns the default configuration to the tenant and there are no setting objects", and the default of EnableGroupCreation is true (overview of group settings). A restriction sets EnableGroupCreation to false and puts one group's identifier in GroupCreationAllowedGroupId, and "Only one group in your organization can be used", with others nested inside it (manage who can create groups). The reading is that object and its values (group settings cmdlets):

# Illustrative and read-only; Microsoft Graph PowerShell beta module, not run for this article.
# No Group.Unified object means the tenant is on the defaults.
$setting = Get-MgBetaDirectorySetting | Where-Object { $_.DisplayName -eq "Group.Unified" }
$setting.Values | Where-Object Name -in "EnableGroupCreation", "GroupCreationAllowedGroupId"

The values are not the whole answer. "The steps in this article can't prevent members of certain roles from creating Groups", and Microsoft lists those roles, from Exchange Administrator to User Administrator; changes "can take 30 minutes or more to take effect"; and an OWA mailbox policy can block members of the allowed group (manage who can create groups, above). Microsoft's own check is behavioural: a user outside the group, and not an administrator, tries to create a plan in Planner and should be told that creation is disabled (same source). Our reading: the record needs the values, the allowed group and its membership, nested groups included, and the role list beside them as the documented exception.

Audit: the right cmdlet in the wrong shell

Audit logging "is on by default for Microsoft 365 organizations", says Microsoft's page on turning it on or off, and the same page says it "isn't enabled by default" for Business Basic, Business Standard and Business Premium. The documented reading is Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled in Exchange Online PowerShell, with a warning: in Security & Compliance PowerShell, the same property "is always False, even when auditing is turned on". A document that says auditing is on, checked in the wrong shell, is contradicted by a reading that can say nothing else. A reading is a command, a property and a shell, and the record names all three.

What we recommend, in order

These are our recommendations, not NIST's or Microsoft's.

1. Write each control as one checkable sentence with its expected value, with the ID, statement and scope CAF asks for, and any exception Microsoft documents.
2. Name an owner and a deputy who stay, and the person who grants exceptions.
3. Write the reading down exactly: the command, page or endpoint; the shell; the property; which value, effective or stored; the role needed to run it; and what an empty result means.
4. Take the first reading the documented way before signing, and record the value, the date and who read it. Until then, the line is a claim.
5. Report every review control by control, as recorded, changed or not read. A change goes to its owner, an unread control is reported unread, and nothing is added into a figure.
6. Date each review by its basis: a frequency you state with its reason, the events CAF names, and changes that reopen other controls, such as any change to the organisation's sharing level.
7. Keep the testing type beside every status in a compliance tool, and look at it again after attaching evidence.

What this does not settle

• Whether Get-SPOSite -Identity returns SiteDefinedSharingCapability in current module versions. The reference lists it under -Detailed, which it describes as deprecated. Check that the property is populated before relying on it.
• Whether Get-SPOTenant is a documented reading of the organisation's sharing level. Its reference names storage and site-creation properties only, so we used Graph's documented sharingCapability.
• Whether attaching a single evidence file to an automatically tested action switches it to manual. The setup page says adding "testing data or evidence" does; the update page it links to describes a bulk import. Check the testing type afterwards.
• Which licences the group creation restriction needs. The group creation page requires Entra ID P1 or P2 for the admin and the allowed members; the Graph overview says GroupCreationAllowedGroupId needs no P1; the Entra cmdlet page exempts only EnableGroupCreation from P1.
• Whether a setting that reads as documented works. A reading establishes the setting, not that the control is "operating as intended" (CA-2), which needs evidence of its own, such as Microsoft's Planner check.

Where this fits

• Chapter 39 of the Field Guide hands over every SharePoint control with an owner, a documented reading and a review date, and reports each review as recorded, changed or not read. This article is the general case behind those fields.
• Chapter 6 writes governance as rules before a migration, on the principle that "a rule nobody can check against evidence is a preference". Here the rule is the document, and the evidence is its reading.
• The confident wrong answer is worse than missing evidence shows what a listing returns for a site's sharing it never populated. A documented reading excludes that path by name.
• The last Graph page is not proof of tenant coverage separates an exhausted read from a complete population. A per-site reading is only as complete as its list of sites.
• SharePoint HTML pages are governed by a setting your custom script audit does not read is the case where the documented setting is real and the control lives elsewhere.
• A report can look complete and still be impossible to verify argues that an artefact nobody can check without its producer has been re-asserted, not verified. A document without its reading is in the same position.

Sources, checked on 7 November 2026

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0 (CM-1, CM-2, CM-6, CM-8, CA-2 and SA-5)
• Cloud Adoption Framework: document cloud governance policies, monitor cloud compliance, administer your Azure cloud estate
• Well-Architected Framework: architecture strategies for standardizing operations
• Microsoft Purview Compliance Manager: working with improvement actions, get started with Compliance Manager, Compliance Manager scoring, update improvement actions
• Microsoft Purview Audit: turn auditing on or off
• SharePoint: overview of external sharing, change the sharing settings for a site, Get-SPOSite, Get-SPOTenant
• Microsoft Graph: sharepointSettings, get settings, overview of group settings
• Microsoft 365 and Microsoft Entra: manage who can create Microsoft 365 Groups, Microsoft Entra cmdlets for configuring group settings

Tags#governance#sharepoint#evidence#engineering