How IT Compliance Audits Work and Where Access Evidence Fits

IT compliance audits assess technology controls against defined requirements using evidence, not simply a collection of policies. Auditors establish the scope, understand how controls should work, examine what happened and report their conclusions. Access evidence fits wherever the audit question concerns who could use a system, who authorised that access and how changes were handled. Citadel Identity360 helps produce evidence for that identity portion, while auditors retain responsibility for testing and judgement.

IT compliance audits begin with a question, not an export

An IT compliance audit asks whether selected technology practices meet specified criteria within an agreed boundary. The boundary might be an internal policy, contractual commitment or regulatory requirement. It identifies systems, activities, organisational units and the period under examination. An access report becomes useful only after that question is clear.

For example, a list of current administrators may help answer who holds privilege today. It cannot, by itself, explain whether approval rules operated during an earlier period. Likewise, a policy describing termination procedures says what should happen; it does not show how individual departures were handled.

This article follows the engagement from planning through follow-up. It is distinct from the continuous-versus-periodic compliance discussion, which concerns operational cadence, and the compliance management system guide, which explains programme ownership. Here the practical question is how identity teams supply material an auditor can actually test.

Separate the engagement from the framework

There is no universal IT compliance audit with one mandatory checklist. Internal audit engagements, security control assessments and financial-reporting audits have different purposes. Their evidence requirements should not be collapsed into one generic pass-or-fail exercise.

The IIA Global Internal Audit Standards describe engagement planning, developing findings and conclusions, collaborating with management on recommendations or action plans, and communicating during and after the engagement. That is an internal audit context.

NIST SP 800-53A provides a methodology and assessment procedures for security and privacy controls. Its procedures can be tailored to organisational risk management needs. It is not a blanket requirement that every enterprise run the same assessment.

PCAOB AS 1105 addresses evidence in the financial-statement and related ICFR audit setting. Its distinctions between quantity, quality, relevance and reliability are useful here, but its requirements belong to that setting. For the financial-reporting access-control angle, use the separate SOX access controls article.

Working vocabulary for the evidence conversation

A short shared vocabulary prevents teams from delivering the right file for the wrong question:

• Criteria: the requirements or expectations against which the activity is assessed.
• Scope: the boundary identifying what the engagement examines and what it does not.
• Control objective: the intended result, such as limiting sensitive access to authorised roles.
• Population: the complete set of relevant items from which testing may be selected.
• Sample: selected items examined under the testing approach, not a convenient handful chosen by the control owner.
• Evidence: information used to evaluate the activity against the criteria, including information that challenges the expected conclusion.
• Finding: a documented gap or other result developed through evaluation, rather than an unexplained alert.

A control owner operates the activity. An evidence custodian retrieves and explains records. The auditor decides how to evaluate them. One person may assist in several conversations, but these responsibilities should remain explicit.

Planning translates requirements into evidence requests

Before fieldwork, identity teams should ask what each requested item is meant to demonstrate. An auditor may want the population of access changes, the process for approving them, examples of completed changes or the results of management reviews. Those are related, but not interchangeable, deliverables.

Agree application names, identity types, relevant dates and the meaning of each status. Explain whether a population includes disabled accounts, service identities and indirect group membership. If an application is outside scope, record that decision in engagement documentation rather than silently leaving it out of the export.

A practical request description includes:

• The control objective and the system or process being examined.
• The reporting period or snapshot date, including its time zone.
• The population definition and any documented exclusions.
• The source, extraction approach and responsible contact.
• The expected link between decisions, fulfilment and review records.

Also agree how sensitive exports will be transferred, who may receive them and where working copies should be stored during the engagement.

These are preparation recommendations, not a universal regulatory template. They make disagreements visible before someone spends days formatting a spreadsheet that cannot answer the audit question.

Fieldwork combines explanation with examination

Auditors need more than a confident account of the process. In the financial audit context, AS 1105 says inquiry alone is insufficient to support a conclusion about control effectiveness. It describes inspection, observation and reperformance among the available procedures. The chosen procedure depends on the audit purpose.

A walkthrough helps explain the route from a request to its handling. A test then evaluates selected evidence against the criterion. Demonstrating one clean request is not equivalent to establishing that every request in a period was handled properly. A screen demonstration and a historical population answer different questions.

Identity teams should preserve that distinction when presenting Citadel Identity360. Show how records relate, identify the source of each field and explain unfinished work honestly. Do not present a platform dashboard as the auditor’s conclusion. The platform supplies material for evaluation; the engagement determines what that material establishes.

Access evidence has several different jobs

Define the people and permissions being tested

An account list establishes a population only when its scope is understood. Application accounts, directory identities and business identities may have different identifiers. Record the joins used to relate them, and investigate records that cannot be matched rather than excluding awkward rows.

Membership in a role or group may explain access differently from a direct entitlement. Citadel’s access-path discovery helps trace how access was granted and the approver involved. That relationship context is useful when an apparently simple account list conceals several routes to the same resource.

Connect authorisation to the change requested

Request and approval records explain business decisions. Fulfilment records explain the handling of the approved work. Keep those concepts separate: approval is not completion, and an open removal is not a completed removal.

For selected items, provide the decision and the associated fulfilment trail. Changes should be followed through to completion. Where an administrator must perform a step, its status should remain visible instead of being replaced by an assumption that sending a message finished the work.

Show what reviewers decided

A certification campaign provides decisions about existing access. Useful supporting material includes the campaign boundary, reviewed access items and resulting actions. A launch notice is not the same as a completed review, and a revoke decision should remain connected to subsequent work.

The knowledge-centre explanation of access certification describes the review concept. For an engagement, ask which campaign outputs address the selected control rather than sending every review ever performed.

Reliability matters before sample selection

AS 1105 distinguishes sufficiency, meaning evidence quantity, from appropriateness, meaning relevance and reliability. More copies of a weak source do not repair its quality. For company-produced information, the standard addresses testing accuracy and completeness, or controls over them, and evaluating precision and detail.

For identity teams, a practical implication is to explain how an export was produced. Preserve the original output separately from presentation edits. Document filters, transformations and the reconciliation between application identifiers and governance records. If two reports disagree, investigate the reason rather than selecting the prettier result.

Suggested checks include:

• Compare the stated date range with the report parameters.
• Account for exclusions, duplicate rows and unmatched identities.
• Distinguish extraction time from the period the records describe.
• Preserve evidence of how a spreadsheet was transformed.
• Identify access restrictions affecting the reviewer or export operator.

These steps help an auditor understand the information. They do not remove the auditor’s responsibility to evaluate it or dictate a particular sample size.

A payroll walkthrough, clearly illustrative

Consider an illustrative audit of payroll application access. The agreed objective concerns approval of role changes and review of sensitive permissions during the period. The audit team defines the population and testing approach; identity operations explains the available records.

A selected transfer shows the worker moving between departments. The evidence package connects the business event, the access decision and fulfilment status. A later review records the decision about remaining payroll rights. If removal work is still open, operations presents it as unfinished and names the responsible team.

Management maintains finding responses and action plans through its established audit process. Identity records provide the relevant decision and change history; they do not automatically become the entire audit workpaper file.

If a report omits payroll administrators because they use separate accounts, the population needs attention before further testing. That omission is not solved by producing more screenshots of ordinary users. The question remains whether the evidence covers the people and permissions the engagement actually selected.

For preparation between engagements, the article on automating identity evidence addresses ongoing collection. During an engagement, however, give each request a clear owner and preserve the relationship between the original question and the delivered material. If the auditor changes the boundary, record the change rather than quietly replacing an earlier export. This keeps the discussion about what was tested, not competing versions of an attachment.

Reporting should distinguish findings from repair work

A report brings criteria, evaluated evidence and conclusions together. Management then needs a practical response to identified gaps. Repairing one access item and changing the process that created the gap are different activities; both may deserve follow-up.

The IIA standards page explicitly includes communication of engagement results and monitoring action plans among its principles. In practice, agree who owns the response and how progress will be assessed. Avoid relabelling a task as finished simply because a deadline has passed.

This article addresses engagement mechanics and the contribution of identity records. It does not prescribe audit opinions, legal interpretations, retention periods or the full control catalogue for any particular regime. Those decisions belong to the applicable requirements and engagement context.

Citadel Identity360 makes the identity portion usable

Citadel Identity360 brings lifecycle orchestration, access decisions and review activity into the identity governance workflow. For an audit team, the useful connection is between the business decision and its handling, rather than another isolated folder of screenshots.

Its relevant capabilities include:

• Lifecycle operations: joining, job changes and departures drive provisioning and deprovisioning orchestration across the identity estate.
• Relationship visibility: the identity graph presents users, roles, applications and permissions, while access-path discovery explains the grant route and approver.
• Review context: scheduled campaigns give reviewers risk information alongside AI-generated recommendations. Reviewers remain responsible for decisions.
• Risk attention: toxic-combination monitoring and identity risk scoring help prioritise investigation without claiming that every conflict is prevented before a grant.
• Evidence production: governance reporting helps produce records for access-related control evaluation; the auditor determines their suitability.

Hybrid applications still need workable fulfilment paths. Citadel supports connectors and directory, database, file and batch approaches. RPA can carry configured administration steps through application interfaces, and governed manual fulfilment handles work assigned to administrators. These are different delivery paths, not a promise that every application supports identical operations.

Choose deployment on customer premises, private cloud or SaaS according to operational responsibilities. Routine administration is no-code-first. Keep the demonstration centred on a real evidence question, not an assumption that software substitutes for an audit methodology.

Questions raised when the evidence request arrives

Does an IT audit examine every security control?

Not automatically. The objective and agreed boundary determine which activities are examined. Identity operations should understand that boundary before preparing populations or arranging demonstrations.

Can a current access list answer a historical audit request?

Only if it actually addresses the requested period and question. A present-day snapshot alone does not describe every earlier access decision. Explain available history and any limits directly.

Who chooses which access records get tested?

The auditor determines the testing approach for the engagement. Control owners explain the population and retrieve requested material; they should not substitute convenient examples for the selected items.

What if a removal is still being processed?

Show its actual status and the work remaining. Keep the approved change connected to fulfilment activity. Do not collapse an approval, an instruction to an administrator and a completed change into one status.

Does continuous evidence collection replace fieldwork?

No. Ongoing collection supplies information, while fieldwork evaluates it against the engagement criteria. Access evidence still needs an appropriate population, relevant period and understandable provenance.

How should we demonstrate Citadel to the audit team?

Start with one scoped application and a question about a role change or review decision. Trace the related records, explain the source data and include unfinished work. Let auditors decide which further procedures they need.

Bring one evidence question to the demonstration

Take an access question from the next engagement and walk its population, approval, fulfilment and review material through Citadel Identity360. Ask how the records will be presented and who will explain them during fieldwork. Request Demo to explore that workflow, or watch the product video preview before choosing the application.