← All guides

Methodology · GVISION KNOWLEDGE

Prepare for an IT audit: documents, access and evidence to collect

Structured preparation reduces disruption, improves conclusions and lets the auditor spend more time on real risks.

Prepare for an IT audit: documents, access and evidence to collect

Key takeaways

The complete checklist for scope, stakeholders, inventories, configurations, contracts, logs and tests.

A relevant audit starts with the services the business must continue to deliver, the information it cannot afford to lose and the commitments it must meet. Technical scope follows. This prevents teams from spending time on a peripheral device while overlooking a cloud account, supplier or restoration process on which operations genuinely depend.

The NIST Cybersecurity Framework 2.0 organises risk management around six functions — govern, identify, protect, detect, respond and recover — while the Centre for Cybersecurity Belgium's CyberFundamentals Framework translates these principles into practical, proportionate measures. Frameworks do not replace judgement; they reduce blind spots and create a common management and technical language. [1][2]

In this guide, a control is reliable only when it has an owner, consistent configuration, known coverage and recent evidence. A purchased licence, enabled checkbox or old document is not enough. Effectiveness is demonstrated through use, monitoring, testing and the ability to remediate exceptions.

The result must remain understandable over time. For each conclusion, record the observation date, covered systems and populations, method, sample and limitations. Separate observed facts from statements and auditor assumptions. This traceability lets another person understand the rating, repeat the verification after remediation and measure progress during the next review. It also prevents two common errors: assuming a control applies everywhere when only part of the scope was checked, or keeping an action open indefinitely without an objective closure criterion. Provide two reporting levels: a concise management view for decisions and technical detail for implementation. Both should use the same priorities and clearly identify risks that are accepted, transferred, reduced or avoided. The report then becomes a governed working instrument rather than a snapshot forgotten after presentation.

  • Scope, method and audit quality

    Report value depends on precise scope, quality evidence and separation of facts, assumptions and limitations. The method must be proportionate to risk.

  • Governance, accountability and risk

    Verify who decides, performs, checks and accepts risk. Informal accountability delays incident response and makes exceptions difficult to govern.

  • Inventory and lifecycle

    An unknown environment cannot be protected consistently. Cover hardware, software, cloud services, service accounts, data, owners and end-of-support dates.

  • Microsoft 365, cloud and collaboration

    Cloud changes responsibility without removing it. Examine tenant configuration, identities, sharing, applications, logs and licensing choices.

  • Backups and restoration

    A successful job does not prove operations can resume. Link coverage to loss and time objectives, then observe a restoration test.

01

Methodology

Scope, method and audit quality

Report value depends on precise scope, quality evidence and separation of facts, assumptions and limitations. The method must be proportionate to risk. [1]

This domain must be examined through real operations rather than a declared procedure alone. The auditor links people, technology and data flows to the business scenario in this guide. Exceptions matter too: a protection enabled broadly may still leave critical accounts, devices or data outside its coverage.

The method compares the expected, configured and actually observed states. Interviews explain intent; administration screens, exports, logs and tests demonstrate application. Where intrusive verification is not authorised, that limitation must be explicit in the report to avoid an overconfident conclusion.

Checks to perform

  • Define inclusions, exclusions and constraints
  • Identify interviewees, evidence and access
  • Choose suitable samples and tests
  • Validate facts before conclusions
  • Separate recommendations, obligations and options

Evidence to request

  • Engagement letter and scope
  • Test plan and evidence register
  • Readout record

Each gap is then qualified by likelihood, impact and ease of exploitation. The recommendation should name the expected result, action owner, dependencies and evidence needed for closure. This discipline turns a technical list into a governance decision.

Expected decisions and actions

  1. 1Remove ambiguity
  2. 2Trace evidence
  3. 3Track actions after the readout
02

Methodology

Governance, accountability and risk

Verify who decides, performs, checks and accepts risk. Informal accountability delays incident response and makes exceptions difficult to govern. [2]

This domain must be examined through real operations rather than a declared procedure alone. The auditor links people, technology and data flows to the business scenario in this guide. Exceptions matter too: a protection enabled broadly may still leave critical accounts, devices or data outside its coverage.

The method compares the expected, configured and actually observed states. Interviews explain intent; administration screens, exports, logs and tests demonstrate application. Where intrusive verification is not authorised, that limitation must be explicit in the report to avoid an overconfident conclusion.

Checks to perform

  • Name an executive sponsor and operational owner
  • Link IT risks to the enterprise risk register
  • Check policy approval and review dates
  • Identify risk acceptances and expiry dates
  • Separate execution from validation

Evidence to request

  • Responsibility matrix
  • Risk register and minutes
  • Approved policies and metrics

Each gap is then qualified by likelihood, impact and ease of exploitation. The recommendation should name the expected result, action owner, dependencies and evidence needed for closure. This discipline turns a technical list into a governance decision.

Expected decisions and actions

  1. 1Assign every major risk
  2. 2Set a governance rhythm
  3. 3Document exceptions
03

Methodology

Inventory and lifecycle

An unknown environment cannot be protected consistently. Cover hardware, software, cloud services, service accounts, data, owners and end-of-support dates. [3]

This domain must be examined through real operations rather than a declared procedure alone. The auditor links people, technology and data flows to the business scenario in this guide. Exceptions matter too: a protection enabled broadly may still leave critical accounts, devices or data outside its coverage.

The method compares the expected, configured and actually observed states. Interviews explain intent; administration screens, exports, logs and tests demonstrate application. Where intrusive verification is not authorised, that limitation must be explicit in the report to avoid an overconfident conclusion.

Checks to perform

  • Compare inventory, directory, network and management tools
  • Find unsupported equipment and software
  • Assign business and technical owners
  • Document join, change and retirement events
  • Include SaaS and third-party access

Evidence to request

  • Asset and licence exports
  • Contracts and support dates
  • Diagrams and application lists

Each gap is then qualified by likelihood, impact and ease of exploitation. The recommendation should name the expected result, action owner, dependencies and evidence needed for closure. This discipline turns a technical list into a governance decision.

Expected decisions and actions

  1. 1Create one source of truth
  2. 2Investigate unknown assets
  3. 3Plan replacements
04

Methodology

Microsoft 365, cloud and collaboration

Cloud changes responsibility without removing it. Examine tenant configuration, identities, sharing, applications, logs and licensing choices. [4]

This domain must be examined through real operations rather than a declared procedure alone. The auditor links people, technology and data flows to the business scenario in this guide. Exceptions matter too: a protection enabled broadly may still leave critical accounts, devices or data outside its coverage.

The method compares the expected, configured and actually observed states. Interviews explain intent; administration screens, exports, logs and tests demonstrate application. Where intrusive verification is not authorised, that limitation must be explicit in the report to avoid an overconfident conclusion.

Checks to perform

  • Review Secure Score without treating it as a guarantee
  • Check MFA, Conditional Access and privilege
  • Analyse external sharing and guests
  • Check logs, alerts and retention
  • Inventory OAuth applications and integrations

Evidence to request

  • Entra, Defender, Exchange and SharePoint exports
  • Secure Score
  • Audit logs and application list

Each gap is then qualified by likelihood, impact and ease of exploitation. The recommendation should name the expected result, action owner, dependencies and evidence needed for closure. This discipline turns a technical list into a governance decision.

Expected decisions and actions

  1. 1Reduce persistent access
  2. 2Limit anonymous sharing
  3. 3Enable useful detection
05

Methodology

Backups and restoration

A successful job does not prove operations can resume. Link coverage to loss and time objectives, then observe a restoration test. [5]

This domain must be examined through real operations rather than a declared procedure alone. The auditor links people, technology and data flows to the business scenario in this guide. Exceptions matter too: a protection enabled broadly may still leave critical accounts, devices or data outside its coverage.

The method compares the expected, configured and actually observed states. Interviews explain intent; administration screens, exports, logs and tests demonstrate application. Where intrusive verification is not authorised, that limitation must be explicit in the report to avoid an overconfident conclusion.

Checks to perform

  • Map covered and uncovered data
  • Separate at least one copy from production identities
  • Check encryption, immutability and administration
  • Compare frequency and retention with business needs
  • Observe restoration and measure time

Evidence to request

  • Job reports and alerts
  • Restoration test history
  • Architecture and backup accounts

Each gap is then qualified by likelihood, impact and ease of exploitation. The recommendation should name the expected result, action owner, dependencies and evidence needed for closure. This discipline turns a technical list into a governance decision.

Expected decisions and actions

  1. 1Isolate a copy
  2. 2Close coverage gaps
  3. 3Schedule restorations

Turn the audit into a roadmap

Turn the audit into a roadmap

A good audit does not end with a score. It organises the move from the observed state to a chosen level of control, with an owner, deadline and closure evidence for every action.

01

Frame the risk

Confirm critical activities, important data, dependencies, obligations and risk appetite with management. Without that context, every fix appears urgent and budgets become scattered.

02

Treat immediate exposure

Start with scenarios combining high likelihood and impact: weakly protected administrator accounts, backups reachable from production, exposed or unsupported systems and insufficient detection capability.

03

Stabilise the foundations

Assign responsibilities, complete the inventory, standardise configurations, document procedures and introduce recurring checks. Security should be repeatable rather than dependent on one person.

04

Prove and steer

Retain configuration reports, logs, test records and risk acceptance decisions. A small number of stable indicators is more useful than a crowded dashboard that triggers no decisions.

05

Reassess

Schedule a review after major changes and at least at a defined frequency. An audit is a snapshot; new users, cloud services, suppliers and equipment continuously change risk.

Preparation checklist

Preparation checklist

Collect these items before the interview. Missing evidence does not automatically mean the control is absent, but it increases verification time and weakens assurance.

  • Define inclusions, exclusions and constraints
  • Identify interviewees, evidence and access
  • Engagement letter and scope
  • Name an executive sponsor and operational owner
  • Link IT risks to the enterprise risk register
  • Responsibility matrix
  • Compare inventory, directory, network and management tools
  • Find unsupported equipment and software
  • Asset and licence exports
  • Review Secure Score without treating it as a guarantee
  • Check MFA, Conditional Access and privilege
  • Entra, Defender, Exchange and SharePoint exports

Frequently asked questions

Frequently asked questions

How much time should this type of audit take?+

It depends on the number of sites, users, devices, cloud tenants and suppliers. A targeted review may take a few hours; a documented engagement covering governance, configurations and evidence usually requires several interviews and analysis time. Write down the scope before work begins.

Is a questionnaire enough to reach a conclusion?+

No. A questionnaire is excellent for directing discussion and revealing unknown areas. A professional conclusion still requires suitable evidence, observation or testing. Unverified answers must be clearly identified in the report.

Must every observation be fixed immediately?+

No. Actions should be prioritised by risk, business impact, effort and dependencies. Some measures reduce several risks at once; others can wait or be replaced by a documented compensating control.

Does an audit guarantee that no incident will occur?+

No audit can guarantee the absence of outages, errors or cyberattacks. It reduces uncertainty, highlights known exposure and improves prevention, detection, response and recovery. Its limitations should be explicit.

How often should the situation be reassessed?+

Set a risk-based frequency and add reviews after major changes: cloud migration, acquisition, new site, supplier change, incident, new obligation or business transformation. Critical actions deserve more frequent follow-up than the full audit.

Official sources and references

Official sources and references

The sources below support the principles and requirements discussed. GVISION recommendations are an operational interpretation for a business context and do not replace legal advice or official certification.

  1. 01
    NIST — The NIST Cybersecurity Framework (CSF) 2.02024https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20 ↗
  2. 02
    CCB · Safeonweb@work — CyberFundamentals Framework2025https://atwork.safeonweb.be/tools-resources/cyberfundamentals-framework ↗
  3. 03
    NIST — CSF 2.0 Small Business Quick-Start Guide2026https://www.nist.gov/cyberframework/quick-start-guides ↗
  4. 04
    NIST — SP 800-34 Rev. 1 — Contingency Planning Guide2010https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final ↗
  5. 05

GVISION KNOWLEDGE

All guides

Move from reading to assessing your own environment.

The complete checklist for scope, stakeholders, inventories, configurations, contracts, logs and tests.

Start the free IT audit Compare audits