The Difference Between Documentation and Implementation: A SharePoint Folder Is Not a Control

Executive answer

A policy stored in SharePoint is not a security control.

Neither is a procedure, a spreadsheet, a completed risk assessment, or a beautifully formatted control matrix.

These are documented representations of what an organisation intends to do.

Implementation begins when that intention changes what people and systems actually do.

This distinction sounds obvious. In practice, it is one of the most common weaknesses in ISO 27001 implementations.

An organisation may have an approved Access Control Policy stating that user access must be reviewed regularly. It may have a procedure describing how the review should happen. It may even have a spreadsheet showing that the review was completed.

But if nobody can reliably identify who performs the review, when it happens, what system generates the population of accounts, how exceptions are handled, who approves them and where the resulting evidence is retained, the organisation has documentation.

It does not necessarily have an effective control.

The practical test is simple:

If you remove the document, does the underlying behaviour still happen?

If the answer is no, the document may be carrying more of the control than the organisation realises.

The operational problem

The SharePoint illusion

SharePoint is not the problem.

Neither are document-management platforms, GRC tools or policy repositories.

The problem is treating the repository as the implementation.

A typical implementation can produce an impressive structure:

• Information Security Policy
• Access Control Policy
• Incident Response Procedure
• Supplier Security Procedure
• Risk Management Methodology
• Business Continuity Policy
• Asset Management Procedure
• Security Awareness Policy
• Change Management Procedure

Everything has an owner.

Everything has a review date.

Everything has been approved.

The folder looks excellent.

Then someone asks a deceptively simple question:

“Show me how this works in practice.”

That is where the difference between documentation and implementation becomes visible.

The Access Control Policy says access is reviewed quarterly.

Who actually performs the review?

The Incident Response Procedure says incidents are classified according to severity.

Where does classification happen?

The Supplier Security Procedure says critical suppliers undergo security assessment.

How does procurement know which suppliers are critical?

The Asset Management Procedure says assets are maintained in an inventory.

Who updates the inventory when a new system is deployed?

The Business Continuity Policy says critical services have recovery requirements.

Where are those requirements recorded, tested and reviewed?

A document can answer what should happen.

Implementation has to answer what actually happens.

The three layers of a control

One useful way to think about implementation is to separate three layers.

Layer 1: The documented requirement

This is the policy, procedure, standard or control description.

It establishes the intended behaviour.

For example:

Privileged access shall be reviewed periodically by an authorised owner.

This is useful.

It establishes an expectation.

But it does not prove that the organisation can reliably execute it.

Layer 2: The operational mechanism

This is where the requirement becomes part of a real process.

Someone needs to receive a review task.

They need access to the relevant population of privileged accounts.

They need criteria for determining whether access remains appropriate.

They need authority to revoke or modify access.

They need a mechanism for recording the decision.

There needs to be a defined response when the review is not completed.

This is implementation.

The control now exists as an operating activity rather than a sentence in a document.

Layer 3: The evidence

Finally, the organisation needs to demonstrate that the mechanism actually operated.

For an access review, that might include:

• The population of privileged accounts reviewed
• The reviewer and their authority
• The date of review
• Decisions made
• Exceptions identified
• Remediation actions
• Closure evidence

The evidence is not the control itself.

It is evidence that the control operated.

This distinction matters enormously during audits.

An auditor is not merely interested in whether a company has written that something should happen.

They need confidence that the organisation has established and operated the relevant processes.

When documentation becomes bureaucracy

Documentation becomes counterproductive when the organisation starts optimising for document completeness instead of operational usefulness.

This usually produces familiar symptoms.

Policies become longer because nobody wants to be accused of leaving something out.

Procedures contain increasingly detailed instructions that do not reflect how employees actually work.

Control matrices are populated with generic statements copied from templates.

Responsibilities are assigned to departments rather than identifiable roles.

Review dates are tracked carefully while the underlying activities are barely monitored.

Eventually, the ISMS develops two versions of reality.

There is the version written in the documentation.

And there is the version employees actually follow.

The larger the gap between those two versions, the weaker the management system becomes.

This is particularly dangerous because documentation can create a false sense of maturity.

A company with 80 approved policies can look more mature than a company with 20.

But if those 20 policies are tightly connected to operational processes and the 80 exist primarily for audit purposes, the second organisation may have the stronger ISMS.

Document count is not maturity.

A practical example: access reviews

Consider a quarterly access review.

The documented procedure says:

1. The system owner receives an access report.
2. The owner reviews all accounts.
3. Inappropriate access is identified.
4. Remediation is requested.
5. The review is approved.
6. Evidence is retained.

On paper, this looks perfectly reasonable.

Now consider how the process works in reality.

The report is generated manually.

Nobody is sure whether it contains service accounts.

The system owner has changed roles.

The report is emailed to three people because nobody knows who should approve it.

One person reviews the spreadsheet but does not record their decisions.

Two accounts are identified as unnecessary.

The IT team removes one account but forgets the other.

Three months later, the next review starts from a completely different spreadsheet.

The organisation technically has an access-review procedure.

It may even have evidence that a review occurred.

But the control is fragile.

A better implementation might connect the identity platform, access-review workflow and ticketing system.

The system generates the relevant population.

The appropriate owner receives the review.

Decisions are recorded against individual accounts.

Exceptions create remediation tasks.

Remediation is tracked to closure.

The resulting records are retained automatically.

The policy has not necessarily become longer.

The implementation has become better.

Another example: supplier security

Supplier management exposes the same problem.

A policy might require security assessments for suppliers that handle sensitive information or provide critical services.

That sounds reasonable.

But implementation requires answers to operational questions.

How is supplier criticality determined?

At what point in procurement is the classification made?

Who performs the security assessment?

What happens when the supplier cannot provide an ISO 27001 certificate or equivalent assurance?

Who can accept the resulting risk?

What happens when the supplier’s security posture changes?

How are exceptions tracked?

Where does evidence live?

If the answer to all of these questions is “the security team keeps a spreadsheet”, the organisation may have created a manual dependency rather than a robust control.

A stronger design connects security requirements to procurement.

Supplier classification occurs during onboarding.

Higher-risk suppliers trigger additional assessment.

Exceptions create explicit risk decisions.

Contractual requirements are tracked.

Periodic reassessment is triggered according to risk.

Changes in supplier status feed back into the process.

Again, the important improvement is not another procedure.

It is the mechanism surrounding the procedure.

Implementation starts where the workflow starts

One of the most useful questions during an ISO 27001 implementation is:

Where does this activity naturally belong?

Do not automatically put the answer inside the ISMS.

If the activity concerns employee access, start with identity and HR processes.

If it concerns software changes, start with engineering and change management.

If it concerns suppliers, start with procurement and vendor management.

If it concerns vulnerabilities, start with security operations and engineering.

If it concerns incidents, start with the incident-management platform.

If it concerns business continuity, start with business-service ownership and continuity planning.

The ISMS should connect these activities into a coherent management system.

It should not become a parallel universe in which every operational activity is duplicated for compliance purposes.

This is one of the strongest ways to reduce compliance overhead.

Do not create a compliance process when an existing operational process can be strengthened instead.

What good looks like

A well-implemented control has a visible path from requirement to behaviour to evidence.

Consider vulnerability management.

The requirement might establish that vulnerabilities are assessed and remediated according to defined risk criteria.

The operational mechanism might involve:

• Vulnerability scanning
• Risk-based prioritisation
• Assignment to responsible teams
• Remediation deadlines
• Exception handling
• Escalation for overdue remediation

The evidence then emerges naturally:

• Scan results
• Vulnerability records
• Severity classifications
• Assigned tickets
• Remediation timestamps
• Approved exceptions
• Management reporting

Nobody should need to invent an audit trail six months later.

The trail already exists because the organisation operates the process.

That is the goal.

The evidence should follow the work

A useful implementation principle is:

Evidence should be a by-product of execution, not a separate administrative activity.

This does not mean every control needs to be automated.

Some controls genuinely require human judgement.

Risk acceptance is a good example.

A senior executive may need to decide whether accepting a particular risk is appropriate for the business.

That decision should not be automated away.

But even there, the surrounding workflow can be structured.

The risk is recorded.

The decision-maker is identified.

The rationale is documented.

The acceptance period is defined.

The decision is reviewed when circumstances change.

The resulting record becomes evidence.

The human decision remains human.

The administrative machinery around it becomes reliable.

A simple implementation test

For each significant control, ask five questions.

1. Who does it?

There should be an identifiable owner or accountable role.

“IT” is usually not sufficiently precise.

2. When does it happen?

Define the trigger or frequency.

Quarterly is useful.

“Periodically” is usually less useful.

A system event may be even better than a calendar interval where appropriate.

3. How does it happen?

Identify the actual workflow, tool or operational mechanism.

If the answer is simply “we follow the policy”, implementation is probably incomplete.

4. What happens when something goes wrong?

Controls are often designed around the happy path.

Real organisations need exception paths.

What happens when the review is missed?

What happens when a supplier fails the assessment?

What happens when a vulnerability cannot be remediated within the required timeframe?

What happens when a control owner leaves the organisation?

A control that has no defined exception mechanism is often less resilient than it appears.

5. What proves it happened?

Identify the evidence before the control goes live.

This forces the implementation team to think about observability rather than documentation alone.

It also exposes weaknesses early.

If nobody knows what evidence a control should produce, there is a reasonable chance that nobody has properly designed how the control operates.

The danger of “implemented” controls

One of the most misleading words in a compliance project is:

Implemented.

A control is marked green in the control matrix.

But what does green actually mean?

Does it mean the policy exists?

Does it mean someone has agreed to perform the activity?

Does it mean the process has operated once?

Does it mean the control has operated consistently for six months?

Does it mean the organisation has tested its effectiveness?

These are materially different states.

A mature implementation should distinguish between them.

For example:

Designed — The organisation has defined how the control should operate.

Deployed — The required process, technology or responsibility has been put into operation.

Operating — The control has actually been performed.

Effective — Evidence indicates that the control is achieving its intended objective.

This distinction prevents a common implementation mistake: declaring victory as soon as the documentation is approved.

The role of the GRC function

This is also where good GRC teams add value.

GRC should not become the organisation’s professional policy-writing department.

Its role should be to create coherence.

GRC can establish the control framework, define requirements, coordinate risk decisions, monitor control performance and maintain assurance.

But operational teams should own the processes that actually make the controls work.

Security governance should connect the pieces.

It should not become another layer of work sitting on top of them.

That distinction becomes increasingly important as organisations grow.

A small company might survive with a security manager manually coordinating everything.

A larger organisation cannot.

At some point, the governance model must become institutional rather than personal.

Implementation and evidence

A practical implementation exercise can therefore move through four stages.

Stage 1: Translate the requirement

Take the policy or framework requirement and express it as an observable business outcome.

Instead of:

“Access shall be reviewed periodically.”

Ask:

“How do we ensure that inappropriate access to critical systems is identified and removed within an acceptable timeframe?”

The second question produces a much better control design.

Stage 2: Identify the operational owner

Find the person or function that already owns the relevant business activity.

Do not automatically assign everything to information security.

Security may define requirements and provide oversight while another function operates the control.

Stage 3: Design the workflow

Determine:

• Trigger
• Inputs
• Decision points
• Responsible roles
• Escalation
• Exception handling
• Outputs
• Evidence

This turns a requirement into an operating process.

Stage 4: Test reality

Do not stop when the workflow has been documented.

Run it.

Perform the access review.

Test the incident process.

Complete the supplier assessment.

Exercise the continuity plan.

Review the resulting evidence.

Then ask the people who performed the activity whether the process actually works.

This last step is often overlooked.

A process can look excellent in a workshop and become unusable when it meets the real organisation.

The engineers, procurement staff, system owners and managers who actually perform the work will usually identify weaknesses much faster than another policy review will.

The implementation test that matters

There is a useful thought experiment for almost any ISMS control:

Imagine that the auditor never asks for the document. Would the organisation still perform the activity?

If yes, the documentation is probably supporting an operational control.

If no, there is a risk that the documentation has become a substitute for implementation.

This is not an argument against documentation.

Documentation matters.

ISO 27001 requires documented information in numerous contexts, and organisations need reliable records to demonstrate that their management system operates.

The mistake is confusing the record of a process with the process itself.

A fire-extinguisher inspection record does not extinguish a fire.

A vulnerability report does not remediate a vulnerability.

An incident-response policy does not respond to an incident.

A risk register does not manage risk.

The operational mechanism does.

Executive takeaway

A mature ISMS does not have to be enormous.

It has to be real.

Policies should establish expectations.

Procedures should make important activities repeatable.

Controls should change behaviour or reduce risk.

Workflows should make ownership visible.

Evidence should emerge from execution.

Management should use the resulting information to make decisions.

That is implementation.

The SharePoint folder still has a place. It can contain the policies, procedures, records and other documented information required to operate and demonstrate the ISMS.

But it should be the record of the system, not the system itself.

The question for leadership is therefore not:

“Do we have the documentation?”

It is:

“If someone opened our systems and watched the organisation operate tomorrow, would they see the controls described in our documentation actually happening?”

If the answer is yes, your ISMS is becoming operational.

If the answer is no, creating another policy is probably not the next step.

Build the mechanism.