SharePoint NDPA Compliance: Platform Capabilities and Governance Responsibilities
SharePoint provides many of the controls an organisation needs to meet its NDPA obligations. It cannot make the governance decisions those controls depend on. An organisation that assumes Microsoft 365 handles compliance because the features exist can miss important gaps until someone asks how those controls are governed in practice.
This article is the fifth pillar of the broader document management governance framework. Information architecture decides what the content is, access control decides who sees it, and lifecycle governance decides how long it lasts.
Compliance is whether an organisation can demonstrate that all three were carried out as intended.
For the general obligations NDPA imposes on any Nigerian business, key features of the NDPA, a starting-point guide for small organisations and NGOs, and audit readiness cover that ground.
The focus here stays narrower: what SharePoint and Microsoft 365 specifically contribute, and where an organisation still has to do the governing itself.
Why SharePoint Is Relevant to NDPA Compliance
Organisations using Microsoft 365 often already have SharePoint running as part of their document storage and collaboration environment, whether or not anyone has thought of it as a compliance tool. It includes access controls, audit logging, retention policies, sensitivity labelling, and automated workflow capability inside the same environment staff already use daily.
Keeping compliance inside daily operations matters because a framework built that way tends to hold up better than one bolted on as a separate system. A separate compliance system can introduce another interface and another place where information has to be maintained. Configuring what’s already there means the controls sit alongside the data and processes staff already use.
None of that makes SharePoint a compliance product on its own. What separates a default tenant from a compliant one is entirely in the configuration: whether retention labels reflect real decisions rather than sitting unused, whether access permissions were assigned deliberately rather than inherited from whoever set up the site first, and whether anyone is reviewing what the audit log captures.
SharePoint provides the raw capability either way. Only one of those two versions is defensible.
How SharePoint Features Map to NDPA Requirements
The table below shows where SharePoint’s built-in capability aligns with a specific NDPA requirement, what that capability helps with in practice, and what still needs to be decided and governed before the alignment means anything.
| NDPA Requirement | SharePoint Capability | What It Helps With | Governance Still Required |
|---|---|---|---|
| Data subject access requests | Metadata-driven search across libraries | Locating every instance of a person’s data faster than a manual search | Someone has to confirm the search covered every relevant location |
| Data correction rights | Version history and audit trails | Evidence of what changed and when | A process for who can approve and action a correction request |
| Data deletion rights | Automated deletion via Power Automate workflows | Systematic removal instead of manual, inconsistent deletion | A decision about what “deleted” means across backups and connected systems |
| Records of processing and lawful basis | SharePoint lists with workflow integration | Centralised, timestamped processing records | A documented legal basis behind each record, not just a timestamp |
| Access restriction | Role-based permissions with MFA | Restricting data to authorised staff | Deciding who’s genuinely authorised, and reviewing that regularly |
| Retention limits | Retention policies and labels | Enforcing a period automatically once it’s set | Deciding what the correct period is for each data category |
| Audit and record-keeping | Microsoft Purview audit logs | A searchable activity history | Someone has to enable, configure, and periodically review it |
| Security monitoring and incident evidence | Monitoring and alerting | Early warning and a record to investigate from | An incident response process that starts the moment an alert fires |
Where the Mapping Breaks Down
The table above describes what SharePoint can do. It doesn’t describe what an organisation has decided, which is where most of the real compliance work sits.
SharePoint has permissions, but somebody still has to decide who should have access to a given library and why. That’s the governance question SharePoint Access Control addresses directly. Retention labels exist, but somebody has to establish the correct retention period for each data category before the label means anything.
Audit logs are a clear example of this gap. Microsoft Purview Audit (Standard) retains audit records for 180 days by default, not indefinitely.
An organisation that turns on auditing and never revisits it can find itself with no evidence for an incident that happened seven months ago, because the retention window quietly expired. Longer retention requires deliberate configuration and, depending on the retention requirement and licensing, may require an upgraded audit capability.
The same pattern applies to consent tracking, deletion workflows, and access reviews: the feature existing is not the same as the requirement being met. A properly configured environment demonstrates that an organisation made decisions and enforced them. A default configuration only demonstrates that Microsoft built the capability.
What Governing This Requires
Retention Policies Matched to Sector Timelines
SharePoint’s retention policies and labels can enforce a period automatically once one is defined, and apply it consistently across a library without relying on individual staff to remember. What they can’t do is decide what that period should be.
Banking, healthcare, and telecoms each carry different retention obligations layered on top of NDPA, and reconciling those is the governance question Document Lifecycle Governance covers in depth.
Here, the relevant point is narrower: once that decision is made, SharePoint’s retention policies are what turn it into something enforced rather than aspirational.
Role-Based Access Mapped to Function
Access control inside SharePoint is a technical mechanism. Deciding who should have access to a given library, and on what basis, is a business decision that belongs to the content owner, not to IT by default. That distinction, along with the responsibility framework behind it, is covered fully in SharePoint Access Control.
The Audit Trail as Evidence
What an organisation may need to produce, whether during an NDPC inquiry or an internal review, is evidence that access and processing decisions were made deliberately and can be traced.
SharePoint’s audit log search is the mechanism that makes this possible, provided it’s been enabled, scoped to the right activities, and retained for long enough to still be useful when someone asks.
A log that exists but was never reviewed, and a retention window that quietly expired before anyone needed it, both produce the same outcome: nothing to show. The evidence is only as good as the configuration behind it.
Data Residency and Cross-Border Transfer
Microsoft 365 offers Multi-Geo capability, which lets an enterprise tenant store SharePoint and OneDrive content in a specified geographic region rather than wherever Microsoft would otherwise place it.
That’s a genuinely useful control for organisations with cross-border data residency obligations, and it’s an enterprise-tier feature most smaller Nigerian tenants won’t have by default.
It’s worth being precise about what this does and doesn’t resolve. Where Microsoft physically hosts a tenant’s data is a separate question from whether an organisation’s own processing activity constitutes a cross-border transfer under the NDPA.
Multi-Geo can help satisfy a data residency requirement once one has been identified; it doesn’t identify that requirement, and it doesn’t substitute for documenting the transfer mechanism and safeguards the Act expects.
Staff Understanding, Not Just Configuration
A correctly configured environment operated by staff who don’t understand why the controls exist tends to fail in practice, whether through workarounds, misclassified content, or ignored alerts. The technical configuration and the people using it need to move together, not one after the other.
Common Challenges
These are the patterns that show up most often once a SharePoint environment has been running for a while, each one eroding the mapping above in a different way.
Permissions That Don’t Match Current Roles
Existing SharePoint permissions rarely match current business roles once a tenant has been running for a few years, since access accumulates faster than anyone reviews it. A person who moved departments eighteen months ago often still has the access their old role required, alongside whatever their new one has added.
Personal Data Outside the Governed Structure
Personal data has a way of ending up outside the organisation’s governed SharePoint structure entirely, in personal OneDrive folders, email attachments, or Teams chats that nobody classified as sensitive. Content living outside that structure may not be subject to the same controls, even where the underlying platform could technically support them.
Unmapped Integration Data Flows
Integrations with other business systems create data flows nobody has mapped, so personal data can leave SharePoint’s governance perimeter without anyone noticing it happened. A Power Automate flow that copies customer records into a third-party CRM means that personal data remains subject to NDPA obligations, while also creating another system, processor, or processing activity that needs to be accounted for.
Governance That Weakens After Go-Live
Governance that was solid at go-live tends to weaken over time as staff turn over and the people who understood the original configuration move on. Retention labels and access policies that made sense to whoever set them up rarely get revisited once that person has left.
Staff Behaviour Bypassing Controls
Staff behaviour can bypass the intended controls entirely, working around access restrictions or sharing settings that feel like friction rather than protection, particularly when nobody explained why they exist. A restriction that’s never justified to the people it affects tends to get worked around rather than respected.
How This Fits the Broader Governance Framework
The other three pillars each answer a different question: what the information is, who should see it, and how long it should last. Compliance sits above all three, asking whether the organisation can show those questions were answered in practice, not just that the tools to answer them exist.
As a result, compliance ends up as the pillar most exposed by weaknesses in the other three. Access decisions that were never documented, retention periods that were never reconciled against sector requirements, or information nobody classified consistently all surface as the same problem here: an audit trail with gaps in it, because the governance behind it had gaps first.
SharePoint and Microsoft 365 provide real capability toward that answer. They don’t provide the answer itself.
When to Bring in Outside Help
A SharePoint environment that’s grown for years without a governance framework behind it is a harder starting point than a fresh implementation, since existing permissions, retention gaps, and unclassified content all need to be assessed before anything new gets built.
Multiple business units or external processors sharing the same tenant, sensitive personal data spread across sites without a consistent classification approach, or regulatory requirements that overlap in ways nobody has reconciled are all signs the work benefits from experience the internal team may not have time to build under a deadline.
The same is true where cross-border processing is genuinely unclear, or where an organisation has experienced, or suspects, a breach and needs to establish what happened.
Where nobody in the organisation currently owns the governance framework as a whole, bringing in outside expertise to establish that ownership tends to be more effective than trying to distribute it after the fact.
Get SharePoint Working for Your NDPA Compliance
If your SharePoint environment already exists and nobody’s certain whether it meets NDPA requirements, that uncertainty is worth resolving before a regulator raises it first.
Our document management systems work covers assessing your current SharePoint configuration against NDPA requirements and closing the gaps between what the platform can do and what’s been governed so far.
It also covers setting up the audit trail you’d need to produce if asked. Contact us to talk through where your environment currently stands.
