SharePoint in the organisation – how not to drown corporate knowledge in digital chaos

For most organisations the company SharePoint is the largest and most varied knowledge store – contracts, policies, procedures, project documentation, HR materials, product docs, financial reports. It should be the source of truth. In practice it is – only when someone deliberately manages it.

Without that discipline documents grow organically. Every team creates its own place, its own naming convention, its own 'new folder', 'new folder (2)'. After three years there are thousands of places, millions of files, dozens of versions of the same offer and nobody who knows which is current. An employee spends 20 minutes looking for a customer contract instead of 2. An auditor cannot reconstruct decision history. The sales director approves an offer using an outdated template.

The second cost is security risk. A former employee still has access to a project library because nobody cleaned up the permissions. Someone shared a link to a confidential document because there is no clear policy on what may be shared. Sensitive documents sit next to public ones because no one labels them. Each event alone seems small. Together they form a risk surface no one is monitoring – until the first incident.

The third cost is the most current one: digital programmes stand on sand. Every project automating document workflow, every AI assistant, every management-reporting effort first surfaces the SharePoint chaos and then forces a clean-up – with schedule slippage and cost overrun. Better to clean up deliberately and earlier than at the start of every next transformation programme.

Order in documents is not one document or one tool. It is a set of deliberate decisions across six areas that together decide whether the organisation works on organised knowledge or in digital chaos. The board and operations directors should understand these areas, because each requires a business decision, not a technical one.

Area 1: how knowledge is grouped. By department (finance, HR, sales, operations, IT, legal) or by process (customer acquisition, contract delivery, hiring, procurement)? The choice has long-term consequences – it decides where people look for information and how the organisation scales as it grows.

Area 2: naming conventions. How do we name projects, customers and document types? Shared conventions are unromantic but without them search returns chaos. A decision like 'every customer has the code ABC-12345, every project has year-number' saves hundreds of hours in later years.

Area 3: describing documents. What, beyond the file name, tells you what the document is? Type (contract, offer, policy), customer, status, expiry date, owner. These details let you find a document in seconds – instead of digging through folders. An AI assistant without these descriptions answers 'I don't know', even when the document exists.

Area 4: who has access to what. Rule of thumb: the simpler the model, the safer it is. Three roles per place – owner (admin), member (edit), visitor (read) – cover 95% of scenarios. Complex models become unmanageable after a year and nobody knows who sees what.

Area 5: document lifecycle. When does a document stop being active, when is it archived, when does it disappear. Without this policy active documents sit next to dead ones. It is not just hygiene – it is also a legal requirement (accounting min. 5 years, HR 50 years, project records 3 years after close).

Area 6: protection of sensitive data. Documents with pre-publication financials, medical records or M&A data must be labelled and protected at a different level than public marketing material. Without this layer every link shared by an employee is a risk.

A practical observation from dozens of rollouts: the biggest gain comes from a deliberate decision about how we group knowledge. The modern standard is a flat structure – each place in SharePoint is independent and has an owner, and they all connect into single 'hubs' representing business domains. This removes the labyrinth of nested folders.

From a business view 5–15 such hubs works best: Finance, HR, Sales, Operations, IT, Legal, Marketing, R&D – plus, optionally, regions or group companies. Specific places live under each hub: projects, teams, document libraries. Every one with a clear owner and clear scope.

The antipattern we see in most unmanaged organisations: every team creates its own place, with no link to any hub. After a year there are 800 places, 300 of them abandoned. The fix is simple: new places are only created through a controlled process – with assigned owner, scope, retention and hub link. It does not cost much, and it saves years of mess.

The most important mental shift: the document's description matters more than the folder it sits in. The folder says 'where', the description says 'what'. A document described by five attributes (type: contract; customer: ABC; project: year-number; status: active; owner: legal) is findable in dozens of contexts. The same document inside the folder 'Customer ABC / 2026 / Contracts' is only findable if you already know where to look.

A practical design rule: a few mandatory fields (usually document type, category, owner) plus a handful of optional ones for precision. Too many mandatory fields create friction for the person saving the file. The 2–4 mandatory + 4–8 optional split works for most organisations.

The real step change is automation. An AI assistant or document recognition mechanism can fill most of the attributes automatically at upload time – the employee no longer has to describe every document by hand. This removes the main reason for resistance and dramatically improves the quality of corporate knowledge.

The most common mistake in access design is a complex model built 'because we can'. SharePoint lets you set permissions per document, folder, library, item. After a year of that nobody knows who has access to what. Every new hire inherits 'everything from their predecessor', including things they should not see.

The production rule that works: set access at the place level, not at the individual document level. Everything in a given place follows the same access rules. Exceptions are exceptions – documented and time-bounded. Three roles – owner, member (edit), visitor (read) – cover 95% of scenarios. Each role maps to a company group that HR keeps in sync with the org chart.

The second layer is protection of the most sensitive documents. A document marked confidential – internal or partner-only – cannot be shared externally, regardless of the place's rules. Sensitivity labelling is standard today in regulated sectors and should be standard wherever a company handles financial, medical or IP data.

The third layer is sharing outside the organisation. By default it should be off or limited to a list of trusted partners. 'Anyone can share with anyone' is today one of the most common sources of security incidents – the topic ties into the broader AI governance question, because it also affects what external AI model providers can reach.

Every document in SharePoint has a lifecycle: it is created, evolves through versions, is in active use, becomes inactive, falls under retention, is deleted. Without a lifecycle policy, all these stages mix in one repository – active documents sit next to dead ones.

Retention policies in Microsoft Purview automate this lifecycle. Accounting documents – 5 years. Customer contracts – 10 years. HR documents – 50 years after employment ends. Project documents – 3 years after project close. Once retention expires, documents are automatically deleted or archived. This is not just legal compliance – it is operational cleanliness.

The second element is versioning. By default SharePoint keeps 500 versions per document, which after a year creates significant overhead. A versioning policy per library (e.g. 10 for operational, 50 for regulated documents) is a sensible compromise between audit and cost.

The third element is checkout/checkin. For critical documents (contracts, company policies), enforced checkout ensures only one person edits the document at any time, eliminates merge conflicts and creates a clear change audit trail.

Provisioning – how new sites come into being – is at the heart of governance. In self-service mode, anyone with a licence creates a site with a default template. Within a year the tenant has hundreds of unstructured sites.

Professional provisioning uses Microsoft 365 Groups or PnP Provisioning Templates. A new site is born through a Power Apps form that collects details (name, owner, hub, data classification, retention), triggers Power Automate, which via the Graph API creates the site with a pre-configured template – with metadata, columns, permissions, retention policy and hub connection.

The second mechanism is site lifecycle management. Sites unused for 6 months should be flagged to the owner (recertification); after 12 months – archived; after 24 months – deleted. Without this mechanism the tenant grows exponentially.

The third mechanism is monitoring and reports. Microsoft 365 Admin Center and Microsoft Graph Reports provide data on site activity, storage usage, external users, ownerless documents. These reports should be regularly reviewed by a Center of Excellence (CoE).

The first mistake is no architecture before rollout. The organisation buys Microsoft 365, launches SharePoint and lets anyone create sites. After a year there is chaos and a 'cleanup' attempt begins – which costs many times more than designing governance upfront.

The second mistake is an over-complicated permission model. Per-folder, per-document permissions everywhere. Employees do not know what they can access. Audits take weeks.

The third mistake is missing taxonomy. Each team has its own convention, its own column names, its own values. Search returns dozens of inconsistent results.

The fourth mistake is no retention policy. Documents from 2015 live next to documents from 2026. Storage grows linearly, costs rise, search quality drops.

The fifth mistake is missing owners. Every document, every site, every policy must have one accountable person. Without that, governance is only a document, not an operational process. We design this layer with clients as part of advisory and strategy and solution design engagements.

Most organisations are not starting SharePoint on a greenfield. The tenant exists, has hundreds of sites, millions of documents, inconsistent permissions. Rolling out governance retroactively requires a different approach than designing it upfront.

Step 1: tenant audit. Inventory of all sites, usage, owners, classifications. Scanners (e.g. AvePoint, ShareGate, ControlPanel) automate the process. The output: a map of the real state, often showing 30–50% of sites abandoned or ownerless.

Step 2: target architecture. The design of the target hub-and-spoke architecture, taxonomy and retention policies. Decisions, not implementation.

Step 3: phased migration. First, 1–2 pilots (e.g. Finance plus one project hub), then propagation to remaining areas. Each hub migrates over 6–10 weeks. A full enterprise tenant migration – 6–18 months.

Step 4: ongoing governance. After migration, discipline matters most – provisioning workflow, periodic reviews, retire mechanism, CoE monitoring. Without it, a year later the tenant drifts back to its pre-migration state.

How long does it take to roll out governance in an organisation without prior experience? A first hub pilot 8–12 weeks. A full enterprise rollout with content migration – 6–18 months depending on scale.

Do I need third-party tools (AvePoint, ShareGate)? For small tenants (up to 100 sites), native Microsoft tools are enough. For enterprise (1000+ sites), third-party tools significantly speed up audit, migration and monitoring.

How does governance combine with Microsoft Purview? Purview is the compliance layer – sensitivity labels, retention policies, DLP, eDiscovery. SharePoint governance uses these mechanisms but adds an operational layer: provisioning, ownership, taxonomy.

Does AI (Copilot, IDP) force a governance change? Yes. AI models learn from all available tenant content. Without sensitivity labels and permission policies, Copilot sees documents it should not see. Governance is a precondition for safe AI rollout – we cover this thread in our AI governance for business analysis.

Does SharePoint governance apply only to Microsoft 365? Yes. For organisations on other ecosystems (Google Workspace, Box) similar information architecture principles apply, but the technical mechanisms differ.

How do we measure governance effectiveness? Key KPIs: % of sites with active owners, % of documents with completed metadata, % of active sites (logon in last 90 days), number of external sharing incidents, average time for an employee to find a document.

In a mature organisation, SharePoint is not just 'a place for files'. It is the foundation of the digital workplace – the layer on which approval workflows, copilots, IDP and business analytics live. Without governance, that layer starts to collapse under its own weight. With governance, it becomes an asset that scales with the organisation.

The most sensible first step is not buying tools but designing the target architecture: hub-and-spoke, taxonomy, permission model, retention, lifecycle. From there, the rest takes shape across 6–18 months of phased migration and ongoing governance. At AlgorComp we support clients in this stage and deliver enterprise-grade SharePoint governance rollouts.