My evidence-led GRC approach begins with a simple test: if a security or compliance conclusion cannot be connected to reliable information, it is not ready to be treated as fact. A polished policy may express intent, but it does not prove that access is reviewed, backups are restored or suppliers are monitored. Evidence is what lets a reviewer move from “the organization says” to “the organization can demonstrate.”

This does not mean collecting every screenshot or turning an ISMS into an archive. It means designing a proportionate chain from business context and risk to controls, owners, operation and retained records. That chain makes ISO 27001 readiness more useful to management and more defensible during internal or external review.

My working principles
  • Understand the organization before selecting or assessing controls.
  • Treat documents as statements of intent and operational records as evidence of practice.
  • Preserve the source, date, scope and reviewer behind material conclusions.
  • State uncertainty and missing information instead of generating confidence.
  • Use automation to assist people, never to disguise an unsupported judgment.

Start with context, not a control checklist

A checklist is useful only after the assessment knows what it is checking. I start by asking what information matters, which services depend on it, who relies on those services, where the information moves and which legal, contractual or operational obligations affect the system. Scope is not administrative decoration; it determines which people, processes, locations, technologies and interfaces the ISMS must address.

Without context, a control can appear complete while missing the real risk. A generic supplier questionnaire may say that contracts contain security terms, for example, but the important cloud service could still use an unapproved subprocessor or retain prompts longer than expected. The evidence-led path moves from the actual dependency to the actual decision and record.

Connect risk decisions to the Statement of Applicability

Risk assessment should lead to treatment decisions, not sit as an isolated spreadsheet. For ISO 27001, the Statement of Applicability becomes a key bridge: it records which necessary controls are included, why they are relevant, their implementation state and why reference controls are excluded where appropriate. I also find it useful to identify owners and linked evidence, even when those fields are maintained in connected registers rather than the SoA itself.

The important part is traceability. A reviewer should be able to follow a risk or requirement to a treatment choice, see the applicable control and inspect evidence of implementation. If the control changes, that relationship should be reviewed. If a risk changes, applicability should not remain frozen simply because last year's document was approved.

Separate policy, implementation and effectiveness

I use three questions when reviewing a control. First, is the expected practice defined? Second, is it operating? Third, does the available evidence indicate that it works as intended? These questions prevent a common mistake: marking a control complete because a policy template contains the right words.

For an access-review process, the policy may define frequency and ownership. Implementation evidence might include the current user list, review record, approval and removal ticket. Effectiveness may require sampling whether inappropriate access was identified and resolved on time. The evidence varies by organization, but the distinction remains useful.

Evidence also needs qualities beyond existence. It should be relevant to the criterion, cover the stated period and scope, come from a dependable source and be sufficient for the conclusion. One carefully selected record may be more persuasive than a folder of unlabeled files. When sampling is used, its basis and limitations should be clear.

Write findings that can be acted on

A finding should tell the reader what criterion was used, what evidence was examined, what condition was observed and why the difference matters. I avoid dramatic language when the evidence supports a narrower statement. I also avoid weakening a real gap into a vague “opportunity” merely because a direct finding is uncomfortable.

Corrective action should address cause, not only the document mentioned in the finding. If reviews repeatedly fail, uploading a missing review record may close the immediate gap without fixing unclear ownership, poor tooling or an unrealistic schedule. An evidence-led review keeps the action connected to the system that produced the problem.

Why this approach led me to build FANG

Many of these relationships are handled manually across forms, spreadsheets, folders and reports. I began building FANG—Focused Assessment and Narrative Generator—to explore how a structured system could preserve them. The intended workflow associates intake answers, control statuses, evidence references, observations and actions, then uses those facts to support a reviewable narrative.

FANG is an evolving prototype/MVP. It does not certify organizations, conduct autonomous audits or replace competent professional judgment. Its purpose is to accelerate repetitive handling while making the evidence chain clearer. If the system cannot show where a statement came from or which person approved it, that output should not be promoted to a conclusion.

Use language models for language-shaped work

LLMs can be valuable for extracting candidate facts from unstructured policies, summarizing supplied material and drafting readable explanations from structured results. They are probabilistic, however, and can omit, infer or confidently misstate information. I therefore separate their role from deterministic control logic.

A model may suggest that a policy names a review frequency. The system should preserve the source passage and document details. A human should confirm the interpretation. The control status should then follow defined criteria, not the tone of the generated paragraph. This division uses AI where it is helpful without granting it authority it does not possess.

What clients and collaborators should expect

My consulting mindset is direct and proportionate. I want to understand the business outcome, define the boundary, request evidence that answers the question and explain gaps in language the owner can act on. Where information is incomplete, I will say so. Where certification, legal interpretation or specialist technical testing falls outside the role, I will identify that boundary.

I see ISO 27001 and GRC as ways to improve decisions, accountability and resilience—not as theatre for an audit date. Good documentation supports that work, but the final test is whether the system helps people manage information-security risk consistently.

FAQ

What does evidence-led GRC mean?

It means connecting governance and control conclusions to reliable, relevant and traceable information rather than relying only on claims or policy wording.

Does every control require a large evidence pack?

No. Evidence should be proportionate. The objective is sufficient support for the conclusion, with clear scope and provenance, not maximum file volume.

Can AI decide whether an organization conforms to ISO 27001?

AI can assist extraction and analysis, but conformity conclusions require competent human evaluation against defined criteria and organizational context.

Is this approach only for certification projects?

No. The same traceability improves internal governance, risk treatment, assurance and management decisions whether or not certification is the immediate objective.

Sources