Risk-based IT Audit: Checklist for On-site and Remote Audits

A risk-based IT audit is not an “audit light”, but the pragmatic response to a reality many IT organizations know: too many systems, too many dependencies, too little time — and at the same time growing demands from compliance, information security, data protection, customer audits and supervisory law. Risk-based means: you do not examine everything to the same depth, but focus most thoroughly where an outage, a security incident or a compliance breach would cause the greatest damage.

In practice, audits rarely fail for lack of intent, but because of three things: an unclear scope (what really belongs?), insufficient evidence (which proofs are reliable?) and a lack of translation into operations (what changes concretely afterwards?). This article provides a checklist for on-site and remote audits that closes exactly these gaps: with prioritization logic, evidence artifacts, roles/responsibilities and a clear audit perspective on operations, data, interfaces and security controls.

What “risk-based” concretely means in an IT audit

“Risk-based” is often used as a buzzword, but in the audit context it is very concrete. An audit is considered risk-based when scope, depth and sampling are derived from a traceable risk assessment. This requires at least:

• Protection needs of information and services (confidentiality, integrity, availability — the CIA triad).
• Threats and vulnerabilities (e.g. ransomware, misconfigurations, single points of failure, outdated components).
• Impact (service outage, data exfiltration, contractual penalties, reputational damage, regulatory consequences).
• Control maturity (existence, effectiveness and demonstrability of controls).

Important: an audit does not only check whether a policy exists, but whether it is effective in daily operation. Effectiveness becomes visible in repeatable processes, clear accountability and reliable evidence (e.g. tickets, logs, reports, configuration extracts, approvals, RESTore test reports).

On-site vs. remote: differences, pitfalls, decision criteria

Remote audits are efficient, scalable and often sufficient — but they change the available evidence. On-site audits provide additional assurance because auditors can verify environments “with all senses”: access controls, media handling, actual working practices, emergency procedures.

When remote audits typically work well

• Standardized cloud and SaaS services with good export capabilities (logs, configurations, evidence reports).
• Mature ITSM processes (ticketing, change, incident, asset management) with a clean history.
• Centralized Identity & Access Management (IAM) and comprehensive logging.

When on-site audits typically provide more insight

• Sites with their own infrastructure (network, servers, OT/production, labs).
• High physical risks (access control, visitor processes, hardware lifecycle, media disposal).
• Discrepancies between documentation and operational practice (shadow IT, „history“ in people’s heads).

The decision criterion is not “remote is modern”, but: Is the evidence verifiable and complete remotely? If proof can only be “shown” via screen sharing but does not exist as exportable artifacts, remote auditing quickly becomes messy — and ultimately increases effort and findings.

Audit preparation in 10 days: Minimal plan for audit readiness

Many audits arrive at short notice (customer questionnaires, recertification, internal audit). A realistic minimal plan focuses on governance, evidence and risk areas.

1. Day 1–2: Scope and system map: Critical services, data flows, external service providers, sites.
2. Day 2–3: Risk triage: “Top 10” risks per service (Availability, Security, Compliance) including owner.
3. Day 3–5: Evidence folders: Structure for evidence, naming standard, responsible parties.
4. Day 5–7: Control self-test: Sample checks (e.g. 5 changes, 5 users, 2 RESTores).
5. Day 8–10: Manage deviations: Immediate measures vs. remediation plan, document risk acceptance.

A common mistake in preparation is to “quickly try to fix everything”. Better: prioritize transparently, apply immediate measures where they actually reduce risk, and otherwise provide a robust remediation plan with deadlines, owners and dependencies.

Risk-based IT audit: Checklist for on-site and remote assessments

The following checklist is structured to work for both remote and on-site. For each area, typical evidence artifacts are listed. Where on-site is appropriate, this is stated explicitly.

1) Governance, roles and responsibilities (foundation for every audit)

• RACI or responsibility model: Who decides, who operates, who approves, who controls? Evidence: organizational chart, role descriptions, signature rules.
• Policies and standards: Security policy, access policy, logging standard, backup policy, change standard. Evidence: versioned documents, approval records, review cycles.
• Risk management: Risk register (risk list) with assessment, measures, acceptances. Evidence: risk workflows, management approvals.
• Exceptions: How are deviations approved, time-limited and tracked? Evidence: exception forms, tickets, expiry dates.

Audit perspective: Without clear responsibility, findings often become “nobody feels responsible”. Maturity is demonstrated by decisions that are traceable and not merely implicit.

2) Scope, asset inventory and data classification

• Asset inventory (hardware, VMs, container hosts, cloud resources, network components). Evidence: CMDB/inventory export, lifecycle status, owner.
• Application inventory including custom enterprise software and integrations. Evidence: system overview, interface list, dependencies.
• Data classification: Which data are personal, confidential, business-critical? Evidence: data catalog, classification rules, mapping to systems.

On-site benefit: reconciliation between inventory and actual infrastructure (unmanaged devices, „forgotten“ network segments).

3) Identity & Access Management (IAM): Access as the primary attack surface

• Joiner/Mover/Leaver process: onboarding, role changes, termination. Evidence: HR triggers, tickets, deprovisioning evidence.
• Privileged Access (admin rights): separate admin accounts, MFA (multi-factor authentication), Just-in-Time/Just-Enough-Access where possible. Evidence: group memberships, PIM/PAM reports.
• Service Accounts: owner, purpose, rotation of secrets, no interactive login. Evidence: account list, secret-store concept, rotation logs.
• Recertification: regular review of critical permissions. Evidence: access reviews, approvals, deviations.

Remote assessment: very feasible if directory services, cloud IAM and logs are exportable. Audit risk: screensharing without export is weak, because evidence is not reproducible.

# Beispiel: Gruppenmitglieder einer Admin-Gruppe (Windows/AD) exportieren
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name,SamAccountName,ObjectClass | Export-Csv .domain-admins.csv -NoTypeInformation

4) Change- und Release-Management: Traceability instead of „heroics“

• Change categories: Standard/Normal/Emergency with clear criteria. Evidence: process description, change templates.
• Segregation of Duties (functional separation): who develops, who deploys, who approves? Evidence: roles in tools, approvals, pipeline permissions.
• Sample (e.g. 5–10 changes): request, risk assessment, test evidence, approval, implementation, backout plan, review. Evidence: tickets, deployment logs, maintenance window communication.
• Emergency changes: subsequent documentation and review. Evidence: post-implementation review, incident reference.

Consequence for operations: good change evidence reduces not only audit findings but also MTTR (Mean Time To Repair), because changes are more quickly traceable.

5) Patch- und Vulnerability-Management: Risk instead of patch rate

• Patch policy: deadlines by criticality, exceptions, maintenance windows. Evidence: policy, approval workflow.
• Vulnerability scanning: scope (servers/clients/containers/cloud), frequency, ownership. Evidence: scan reports, trend over time.
• Prioritization: combination of CVSS (severity) and context (internet-exposed? critical service? exploit available?). Evidence: prioritization rules, tickets with SLA.
• End-of-life: identification and migration plan. Evidence: EOL list, project/action plan.

Remote assessment: good if reports are exportable. On-site benefit: validation of „exceptions“ (e.g. truly isolated? truly compensating controls?).

6) Logging, Monitoring und Zeit-Synchronisation (NTP): Evidence is generated here

• Log sources: authentication, admin actions, system events, security alerts, network/firewall, application logs. Evidence: logging matrix, configuration extracts.
• Central log repository (SIEM/Log-Management): retention, access controls, integrity. Evidence: Retention-Policy, roles, export of events.
• Alerting: critical alerts, escalation, on-call, runbooks. Evidence: alert rules, on-call schedule, ticket history.
• Time synchronization (NTP): consistent time base for forensics. Evidence: NTP configuration, drift reports.

# Example: check NTP status (Linux, systemd-timesyncd/chrony depending on setup)
timedatectl status

Audit perspective: Without retention and access controls, logs are vulnerable as evidence (‚could be manipulated‘). Without correct timestamps, correlations lose value.

7) Backup, RESTore and Disaster Recovery: evidence matters more than concept

• Backup scope: which systems, which data, which frequency? Evidence: Backup-Policy, job list.
• Immutable/offline copies: protection against ransomware. Evidence: storage concept, WORM/Immutability settings.
• RESTore tests: regular RESTores including logs and results. Evidence: RESTore test reports, success rates, findings.
• RTO/RPO: target values for recovery (Recovery Time Objective) and data loss (Recovery Point Objective). Evidence: BIA/DR-Plan, aligned target values.

On-site benefit: inspection of offline media, physical storage, access controls and actual separation. Remote suffices if technical evidence (reports, configurations, test protocols) is present and complete.

8) Network, segmentation and remote access

• Network zones: separation of clients, servers, management, backup, OT, guest. Evidence: network diagram, firewall rules, routing principle.
• Remote Access: VPN/Zero-Trust access, MFA, device compliance. Evidence: configuration, auth logs, device requirements.
• Administrative Interfaces (e.g. iLO/IPMI/management ports): isolated network, RESTrictive access. Evidence: ACLs, jump-host concept.
• Rule reviews: regularly review firewall rules, justify or remove ‚any/any‘. Evidence: review records, change tickets.

# Example: check open ports and listening services locally (Linux)
ss -tulpn

Consequence: segmentation is not only security architecture but affects operations (troubleshooting, deployment paths, monitoring). In an audit it is crucial that the zone logic is documented and practiced.

9) Endpoint and mobile security: the endpoints decide

• MDM/Endpoint management: inventory, compliance rules, encryption, lock screen, jailbreak/root detection. Evidence: compliance reports.
• EDR/AV: coverage, alert handling, tamper protection. Evidence: coverage rate, alerts, response processes.
• Local admin rights: minimization and controlled assignment. Evidence: group policies/profiles, exceptions.
• Shadow-IT: detection via proxy/DNS/SSO logs. Evidence: analyses, measures.

Remote testing: usually feasible via reports. On-site benefit: spot checks on real devices (encryption, patch level, local rights, ‚forgotten‘ notebooks).

10) Applications, interfaces and data flows (including custom enterprise software)

Audit perspective: Especially for process-near software solutions the “technical” scope is often unclear. Explicitly clarify which integrations are part of the audit, because the actual risk often lies there (data exports, batch jobs, SFTP, interface accounts).

11) Third parties and cloud: Demonstrate Shared Responsibility clearly

• Third-Party Risk: Which service providers have access to systems or data? Evidence: Vertragsliste, Zugriffsmodelle, Risiko-Bewertungen.
• Cloud Shared Responsibility: What is the provider’s responsibility, what is yours? Evidence: Cloud-Policies, Konfig-Standards, Verantwortlichkeitsmatrix.
• Proof from provider reports and your own configuration: Evidence: Audit-Reports (sofern vorhanden), eigene Baseline-Checks, Konfig-Exports.
• Exit strategy: data export, key management, identities, dependencies. Evidence: Exit-Plan, Test/Übung (wenn vorhanden).

Important: A provider report does not replace your configuration responsibility. Auditors look at whether you actively manage your side of the responsibility (e.g. IAM, logging, network, encryption).

12) Physical security and on-site operations (only partially verifiable remotely)

• Access: badges/keys, visitor process, logging. Evidence: Zutrittslisten, Berechtigungsreviews.
• Server and network rooms: fire detection/fire-suppression concept (if present), environmental control, UPS, order/labeling. Evidence: Wartungsprotokolle, Fotos als Nachweis (Audit-konform), Begehungsprotokolle.
• Media handling: backup media, media destruction, transport. Evidence: Vernichtungsnachweise, Chain-of-Custody-Prozess.
• Emergency access: Break-Glass-Accounts/Keys, secure storage, four-eyes principle. Evidence: Verfahren, Zugriffsnachweise.

On-site is usually superior here, because auditors can detect circumventions (open doors, shared badges, uncontrolled key issuance).

Evidence strategy: What auditors accept as „robust“

Audit evidence is more than a “screenshot in an attachment”. Evidence is robust when it is reproducible, has a source and is reasonably protected against manipulation. Practical guidelines:

• Exports instead of screenshots, where possible (CSV/PDF/JSON from systems with timestamps).
• Proof of the process chain: Ticket → Approval → Implementation → Review (instead of isolated documents).
• Samples with context: Why was something prioritized? Which exception applies? Who decided?
• Storage and access: evidence folders with clear permissions and retention.

If you collect evidence centrally, a consistent structure (e.g. by control area, system, time period) helps. This not only reduces audit effort but also improves incident response and operational handovers.

Prioritization: Which findings are „critical“ and which are „hygienic“?

Risk-based approaches do not end with the assessment but continue in the management of measures. Not every finding is the same. A practical framework is the combination of Impact and Likelihood (probability of occurrence) plus an „Exposure“ factor (internet-exposed, privileged, critical data).

• Critical: directly exploitable, high impact, missing compensating controls (e.g., admin without MFA, backups without a RESTore test, unpatched internet-exposed systems).
• High: risk can be reduced with clear measures in a short time (e.g., access reviews, segmentation of a management network).
• Medium: process or documentation gaps with indirect risk (e.g., unclear owners in the CMDB).
• Low: cosmetic or of minor security/operational relevance, but relevant for order (e.g., format inconsistencies).

Decision relevance: Executive management and IT leadership should not discuss every detailed deviation, but consciously govern risk acceptances. Acceptance without an expiration date is a typical audit criticism.

Typical remote audit pitfalls (and how to avoid them)

• „We’ll just show it quickly“: Auditors need artifacts, not only live demos. Solution: provide exports in advance.
• Inconsistent time periods: logs and reports from different months make conclusions unclear. Solution: define the audit period and use it consistently.
• Tool sprawl: changes in Tool A, evidence in Tool B, approvals via e-mail. Solution: define the process chain, document breaks, set transitional rules.
• Excessive permissions for audit access: „Here’s admin, otherwise you see nothing.“ Solution: read-only roles, audit-period/export account, logged access.

A clean remote process is also security: it prevents the audit itself from creating a risk (excessive privileges, uncontrolled data distribution).

Costs and operational consequences: Why risk-based audits are usually cheaper

The costs of an audit rarely arise only from the auditor, but from internal time: interviews, evidence collection, rework. Auditing in a risk-based way reduces costs because it focuses the examination and makes rework targeted. At the same time it can create short-term extra work when fundamentals are missing (inventory, IAM structure, log retention). This investment often pays off operationally: fewer incidents due to weak controls, faster root-cause analysis, clearer responsibilities.

As a governance instrument it helps to not treat audits as a one-off event, but as a cadence driver: quarterly self-assessments, semi-annual RESTore exercises, regular access reviews. This significantly reduces the „audit fever“ before the date.

Conclusion: Auditability is an operational outcome

A risk-based IT audit delivers the greatest benefit when you read it as a mirror of your operational capability: Are risks identified, responsibilities clear, controls effective and evidence reproducible? On-site and remote are not opposites but tools. Remote scales, on-site validates where physical reality and practiced operations make the difference.

If you convert the checklist into a recurring self-check, you gain twice: fewer findings in the audit and greater stability in daily operations – from IAM through change to RESTore tests. In terms of content, standards for system documentation, audit-capable change management and integrity evidence for documents fit particularly well and can be integrated as internal guardrails into your governance.

For this topic, the IT audit checklist and remote IT audit are also important. The article places these aspects into context in a comprehensible way and shows what matters in everyday practice.