Every application access review, every segregation of duties rule, every privileged access control and every audit trail in the organization depends on one thing being trustworthy: the directory that says who each identity is and what it belongs to. For most organizations that is Active Directory on premises, Microsoft Entra ID in the cloud, and a synchronization server between them that is, in security terms, both. When the directory is compromised, the attacker does not need to break any application; they become any user, including the administrators, and every downstream control reports that everything is fine. Directory compromise is how most ransomware intrusions become total, and the conditions that make it possible, twenty-six domain administrators, a Kerberos service account password unchanged since 2014, a synchronization server treated as an ordinary virtual machine, are visible in advance to anyone who looks.
This guide is the method for auditing Active Directory and Entra ID as the identity backbone. It explains why the directory is in scope of everything, sets out the privileged groups and roles and the tiering model that contains them, covers the hygiene tests for stale and dangerous objects including the Kerberos issues auditors need to understand for assurance rather than exploitation, group policy change control, trusts, the hybrid synchronization risks, the Entra-specific controls around conditional access, mandatory multi-factor authentication, application registrations and guests, monitoring, an attack-path table that maps each known technique to the control that blocks it and the test that proves the control exists, a fourteen-test program, and a worked example at Lakeshore Bancorp, a public bank whose two-forest directory had accumulated a decade of exceptions. It is the infrastructure chapter of the identity and access management audit and the technical depth beneath the privileged access guide.
In this guide
- Why the directory is in scope of everything
- Privileged groups, Entra roles and the tiering model
- Hygiene: stale objects, dangerous attributes and the Kerberos issues
- Group Policy: configuration that is code, and its change control
- Trusts, forests and the acquired domain
- Hybrid identity: the synchronization server is tier zero
- Recovering the directory: the forest recovery plan nobody has tested
- Entra ID: conditional access, mandatory MFA, applications and guests
- Monitoring: the detections a directory needs
- Attack paths for assurance: technique, control, test
- The fourteen-test program
- Worked example: Lakeshore Bancorp’s two-forest directory
- Common mistakes
Why the directory is in scope of everything
The directory authenticates the users and administrators of nearly every system, distributes the group memberships that applications translate into permissions, and, through group policy, configures the security settings of every domain-joined machine. That makes it a shared layer beneath every application in the ITGC scope and the infrastructure domain of the IAM program: an application’s termination control is only as good as the directory disable that feeds it, its privileged access only as good as the directory groups that grant it, and its audit trail only as trustworthy as the identities the directory vouches for. The directory is therefore tested once, as a system in its own right, with change, privileged access, operations and recovery controls of its own, and referenced from every application’s ITGC matrix rather than re-tested per application. In a hybrid estate the directory is two systems and a bridge: Active Directory holds the on-premises identities and machines, Entra ID holds the cloud identities, applications and conditional access, and the synchronization server copies identities and, usually, password hashes from one to the other, which makes it as sensitive as a domain controller. The audit covers all three.
Privileged groups, Entra roles and the tiering model
Directory privilege is held in a small number of built-in groups and roles whose membership is the first population the audit extracts, directly from the directory with the extraction observed, and compares with the privileged access inventory. Active Directory’s most sensitive groups are Enterprise Admins, Domain Admins, Schema Admins and the built-in Administrators, followed by groups with less obvious but exploitable power: Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins and Group Policy Creator Owners. Entra ID’s most sensitive role is Global Administrator, followed by Privileged Role Administrator, Privileged Authentication Administrator, Security Administrator, Conditional Access Administrator, Application Administrator, Exchange and SharePoint administrators, and any role that can manage credentials. Microsoft’s own guidance sets the benchmarks the audit uses: fewer than five people assigned Global Administrator, fewer than ten assignments of privileged roles overall, multi-factor authentication for every administrator, just-in-time activation through Privileged Identity Management rather than standing assignment, recurring access reviews of role assignments, and two cloud-only emergency access accounts permanently assigned Global Administrator, excluded from conditional access, stored securely and tested.
The model that contains this privilege is Microsoft’s enterprise access model, the successor to the older tiered administration model: control-plane administration (domain controllers, the directory, the synchronization server, Entra privileged roles) is performed only from dedicated privileged access workstations with dedicated administrative accounts that are never used for email, browsing or ordinary work, and those accounts can never log on to lower-tier systems where their credentials could be captured. The audit tests the model by comparison: privileged group members versus their daily-use accounts (are they the same account), privileged accounts’ logon history versus workstations (where have they logged on), and the existence and use of privileged access workstations. Membership in the Protected Users group, which prevents credential caching and weak authentication for its members, and the exclusion of privileged accounts from delegation are the supporting settings. The table gives the populations and tests.
| Population | Benchmark | Test | Typical finding |
|---|---|---|---|
| Enterprise, Domain and Schema Admins; built-in Administrators | Minimal; empty where possible outside change windows; separate admin accounts; no service accounts | Membership extract with nesting expanded; compare with inventory; logon history of each member | Twenty or more members; daily-use accounts; service accounts; vendors |
| Operator groups and DnsAdmins | Empty or justified | Membership; justification | Help desk staff in Account Operators; backup software in Backup Operators |
| Global Administrator | Fewer than five; PIM-eligible not permanent; MFA phishing-resistant | Role assignments with assignment type; authentication methods | Seven or more permanent; on one-time codes |
| Other privileged Entra roles | Fewer than ten assignments; least-privileged role used instead of Global Administrator | Assignment extract; review of each role’s need | Global Administrator used where a scoped role would do |
| Emergency access accounts | Two, cloud-only, excluded from conditional access, credentials in a vault, use alerted and tested periodically | Existence; exclusions; vault record; last test; sign-in alerts | None, or one used as a daily admin account |
| Privileged access workstations | Control-plane administration only from them | Existence; enforcement through authentication policies or conditional access | Administration from ordinary laptops with email open |
| Protected Users and delegation settings | All human privileged accounts in Protected Users; “account is sensitive and cannot be delegated” set | Attribute extract | Neither configured |
Hygiene: stale objects, dangerous attributes and the Kerberos issues
Directories accumulate. Accounts of employees who left before the leaver process existed, computers decommissioned without being removed, service accounts for applications retired years ago, and attributes set in 2009 to make something work are all still there, and each is a path. The hygiene tests are queries against the directory, run by the administrator with the auditor observing, and their results are counted, aged and traced. Three of them require an explanation the audit report will have to give to non-technical readers, and the explanations are for assurance, not for exploitation. Kerberoasting: any authenticated domain user can request a service ticket for any account that has a service principal name, and the ticket is encrypted with that account’s password hash, so a service account with a weak password and a service principal name can have its password recovered offline by anyone with a domain login; the control is long, random passwords or group managed service accounts, and no service principal names on privileged accounts. The Kerberos ticket-granting account: the KRBTGT account’s password signs every ticket in the domain, and an attacker who obtains its hash can forge tickets indefinitely, so the password is reset on a schedule and after any suspected compromise, twice with a gap longer than the maximum ticket lifetime (ten hours by default) so that the second reset invalidates any forged tickets without breaking legitimate ones; a KRBTGT password unchanged since the domain was built is a standard finding. And the AdminSDHolder mechanism: accounts that have ever been in protected groups keep a flag and locked-down permissions after removal, so the count of flagged accounts outside the protected groups is a history of privilege that should be cleaned up. The table lists the hygiene population.
| Condition | Why it matters | Benchmark | Evidence |
|---|---|---|---|
| User accounts inactive over 90 days, enabled | Unowned identities; leaver failures | Disabled at 90 days, deleted after a further period | Last logon extract |
| Computer accounts inactive over 90 days | Stale machines that may return; inventory gaps | Disabled and removed on a cycle | Last logon extract; reconciliation to inventory |
| Password never expires; password not required; reversible encryption | Credentials that never rotate or are stored recoverably | Only justified service accounts with long passwords; none with the other two flags | Attribute extract |
| Accounts with service principal names | Kerberoasting exposure | Group managed service accounts or 25-plus-character random passwords; none privileged | SPN extract cross-referenced to privileged groups and password age |
| KRBTGT password age | Forged ticket exposure | Reset twice on a regular cycle and after any compromise; commonly at least every 180 days | Password-last-set attribute; change records |
| AdminSDHolder-flagged accounts outside protected groups | Historical privilege; permissions anomalies | Cleared on removal | Attribute extract |
| Local administrator passwords | Shared local admin password enables lateral movement | Windows LAPS or equivalent managing unique, rotated passwords on every machine | LAPS deployment coverage; policy |
| Legacy protocols: LM hashes, NTLMv1, SMBv1, unsigned LDAP | Credential capture and relay | Disabled by policy; audited before enforcement | Group policy settings; audit logs |
| Unconstrained delegation on computers or users | Credential theft from any user who connects | None except domain controllers | Attribute extract |
Group Policy: configuration that is code, and its change control
Group policy objects configure the security of every domain-joined machine: password and lockout policy, audit settings, local administrator membership, software restrictions, firewall rules, scripts that run at logon. A change to a policy linked at the domain root reaches every computer within hours, which makes group policy both the most powerful configuration mechanism in the estate and, when uncontrolled, a way to deploy anything to everything. The audit treats it as the change management guide treats any production configuration: who can create, edit and link policies (the Group Policy Creator Owners group and delegated permissions on each object), whether changes go through the change process with approval and testing, whether a change history exists (through policy backups with differences, a management tool, or the directory’s own change auditing), and whether the policies in force match a documented security baseline. The tests are the population of policies with their links and permissions, a sample of changes in the period traced to tickets, a comparison of key settings to the baseline, and a specific look at the policies that grant local administrator rights and run scripts, which are the ones attackers modify.
Trusts, forests and the acquired domain
Trusts connect domains and forests so that users in one can access resources in another, and they are the mechanism by which an acquisition’s neglected directory becomes the main estate’s problem. The audit inventories every trust with its direction, type and age, and tests the two protections that limit what a trusted domain can do: SID filtering, which stops a compromised trusted domain from injecting privileged identifiers, and selective authentication, which limits which resources trusted users can reach. Trusts to domains that no longer exist, trusts created for a project and never removed, and trusts to acquired domains that have never been audited to the standard of the main forest are the typical findings, and the last is the most serious, because an acquired domain with a decade of its own hygiene problems and a two-way trust is a back door into the parent. The IT audit plan treats acquired directories as universe items in their own right; this audit is where they get tested before integration rather than after.
Hybrid identity: the synchronization server is tier zero
Most organizations run Entra Connect or its successor to synchronize identities from Active Directory to Entra ID, usually with password hash synchronization so that users have one password, sometimes with pass-through authentication or federation instead. The synchronization server holds an account with permission to read every password hash in the domain, because that is what synchronization requires, and it holds credentials for Entra ID with permission to write to the tenant. An attacker who controls that server controls both directories, which is why Microsoft classifies it with the domain controllers and why the audit does too. The tests are that the server is treated as control-plane infrastructure: hardened, patched first, administered only from privileged access workstations, excluded from ordinary server administration groups, monitored, and backed up with its configuration exportable for recovery; that the synchronization account’s password is managed and its use is monitored for replication requests from anywhere else; that the tenant-side account holds only the role it needs; and that the synchronization scope is deliberate, so that on-premises administrative accounts are not synchronized into the cloud and cloud administrative accounts are cloud-only. Seamless single sign-on and any federation configuration are tested for their own credential material and its rotation. The backup and recovery guide covers the recovery test for the directory itself, which for the synchronization server means a documented rebuild rather than a restore.
Recovering the directory: the forest recovery plan nobody has tested
When ransomware encrypts an estate, the domain controllers are usually among the first systems taken, and nothing can be recovered until the directory is, because every recovered server needs to authenticate against it. Forest recovery is a specialized procedure: restoring one domain controller per domain from a backup taken before the compromise, in an isolated network, resetting the KRBTGT and every privileged credential twice, cleaning the restored directory of the attacker’s objects, then rebuilding the remaining domain controllers rather than restoring them. Few organizations have documented it and fewer have rehearsed it, and the audit tests four things: that domain controller backups exist, are taken by a method the directory supports, are stored where a domain administrator’s credentials cannot delete them, and are old enough to predate a plausible intrusion; that a forest recovery plan exists with the isolated recovery network, the order of operations and the credential resets written down; that the plan has been exercised at least once, with the restored controller brought up and validated; and that the Entra tenant has its own recovery path, since a synchronized tenant will faithfully replicate a compromised directory’s changes unless synchronization is paused. The backup and recovery guide covers the auditor-selected restore; for the directory, the restore to select is a domain controller, and the finding it produces is usually that nobody knows how long it would take.
Entra ID: conditional access, mandatory MFA, applications and guests
Entra ID’s security is largely a set of policies and objects that the audit reads directly from the tenant with an administrator observing. Conditional access is the enforcement engine: the baseline policies most organizations need require multi-factor authentication for all users, block legacy authentication protocols that cannot perform it, require phishing-resistant methods and compliant devices for administrators, and restrict access by location or risk where the organization has decided to; the audit extracts the policies, reads their scope and exclusions (exclusions are where the gaps live), and confirms that the emergency access accounts are the only exclusions from the administrator policies. Microsoft’s own enforcement now sets a floor: mandatory multi-factor authentication for sign-ins to the Azure portal, the Entra admin center and the Intune admin center was completed in March 2025, and a second phase beginning 1 October 2025 extends it to the Azure command-line tools, PowerShell, the mobile application, REST APIs, SDK clients and infrastructure-as-code tools for users performing resource management, with workload identities such as managed identities and service principals excluded and a postponement available to Global Administrators. The audit asks whether the tenant relied on the postponement and what its plan is, and whether the automation that used human credentials for those tools has moved to workload identities.
Three object populations complete the tenant review. Application registrations and service principals: each has owners, credentials (secrets and certificates with expiry dates), and API permissions, and the findings are applications with high-privilege permissions such as directory write or mail read across the tenant, credentials that never expire or have expired, no owner, and admin consent granted without review; the tenant’s consent policy should prevent users from consenting to applications requesting sensitive permissions. Guest accounts: external identities invited for collaboration, which accumulate and should be governed by an inviter policy, an expiry or review, and restricted directory visibility. And the tenant’s own settings: security defaults where conditional access is not licensed, self-service password reset with strong factors, the audit and sign-in log retention, which is thirty days by default on premium licenses and has to be exported to a SIEM or a storage account to be useful, Identity Protection risk policies where licensed, and the Identity Secure Score as a trend metric rather than a target.
Monitoring: the detections a directory needs
A directory that is administered well is still attacked, and the audit tests that the events which indicate an attack in progress would be seen. The minimum set of detections, from the directory’s own audit logs forwarded to a monitoring platform or from an identity threat detection product, is: changes to privileged group membership and to Entra privileged roles; directory replication requests from machines that are not domain controllers or the synchronization server; a burst of service ticket requests for many service principal names from one account; authentication anomalies for privileged accounts, including logons from ordinary workstations; changes to group policy, trusts and the AdminSDHolder object; creation of application credentials and grants of high-privilege permissions; sign-ins by the emergency access accounts; and disabling of audit settings. The audit inventories the detections, confirms the log sources feed them (domain controller audit policy configured and forwarded; Entra logs exported), samples alerts from the period for handling, and checks retention against the dwell times the incident response audit found. A directory with no detection of privileged group changes has no detective control over its most important population.
Attack paths for assurance: technique, control, test
Auditors do not need to know how to execute directory attacks; they need to know what each one requires, which control removes the requirement, and how to test that the control exists. The table gives the paths that account for most directory compromises in that form. It is the section of the report that explains to the audit committee why a finding about a service account’s password age is rated High.
| Technique | What it requires | Control that removes the requirement | Audit test |
|---|---|---|---|
| Kerberoasting | Any domain login plus a service account with a service principal name and a crackable password | Group managed service accounts or long random passwords; no SPNs on privileged accounts | SPN extract versus password age and privilege |
| Credential theft and lateral movement (pass-the-hash and similar) | Privileged credentials cached on lower-tier machines; shared local administrator passwords | Tiered administration; Protected Users; privileged access workstations; Windows LAPS | Privileged logon history; LAPS coverage; Protected Users membership |
| Replication attack (DCSync) | An account with directory replication rights | Replication rights limited to domain controllers and the synchronization account; monitoring of replication requests | Permission extract on the domain object; detection rule |
| Forged tickets (golden ticket) | The KRBTGT hash | Regular double reset; reset after any compromise; monitoring for anomalous tickets | KRBTGT password age; procedure; detections |
| Group policy abuse | Edit rights on a policy linked to targets | Restricted policy permissions; change control; change auditing | Permissions extract; change tracing |
| Synchronization server compromise | Administrative access to the Entra Connect server | Tier-zero treatment; restricted administration; monitoring | Server admin group membership; hardening; logon history |
| Consent phishing and application abuse | User ability to consent to applications; over-privileged applications with weak credentials | Consent policy; application permission review; credential expiry; owners | Consent settings; application inventory analysis |
| Token theft and session replay | Sessions without device or risk conditions | Conditional access with device compliance and sign-in risk; short session lifetimes for administrators; phishing-resistant MFA | Policy extract; administrator authentication methods |
| Trust abuse | A two-way trust to a weakly controlled domain without SID filtering | SID filtering; selective authentication; trust removal | Trust inventory and settings |
The fourteen-test program
The program is query-driven: nearly every population is a directory or tenant extract, taken by an administrator with the auditor observing and treated as information produced by the entity. Free and commercial assessment tools produce most of the extracts in one run, and using one the organization already owns is efficient; the auditor still confirms the extract’s scope and re-runs the key queries. Where samples are taken, the standard sizes apply.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Extract privileged group and role membership with nesting expanded; compare with the inventory and benchmarks | All privileged groups and roles, both directories | Extracts; inventory; logon history | Oversized groups; daily-use accounts; service accounts; permanent Global Administrators |
| 2 | Test the tiering model: separate accounts, privileged access workstations, logon restrictions | All privileged accounts | Account pairs; logon events by machine; policy enforcement | Administration from ordinary laptops |
| 3 | Test emergency access accounts | The accounts | Existence, exclusions, vault, last test, alerts | Absent; untested; used routinely |
| 4 | Run the hygiene queries | All user, computer and service accounts | Extracts for each condition in the hygiene table | Stale enabled accounts; SPNs on privileged accounts; KRBTGT never reset |
| 5 | Test local administrator password management | All domain-joined machines | LAPS coverage; policy | Shared local admin password |
| 6 | Test legacy protocol and delegation settings | Domain policy; computer and user objects | Settings; delegation attribute extract | NTLMv1 allowed; unconstrained delegation |
| 7 | Test group policy permissions and change control | All policies; changes in the period | Permissions; change history; tickets; baseline comparison | Broad edit rights; untracked changes |
| 8 | Inventory and test trusts | All trusts | Direction, type, SID filtering, selective authentication, justification | Stale trusts; acquired domain unfiltered |
| 9 | Test the synchronization server and accounts | The server, its admins, the sync accounts | Hardening; admin group membership; replication permissions; monitoring; scope configuration | Treated as an ordinary server; on-premises admins synchronized to the cloud |
| 10 | Read conditional access policies and exclusions | All policies | Policy export; exclusion groups; legacy authentication block; administrator requirements | Exclusions covering large groups; legacy authentication allowed |
| 11 | Test mandatory MFA status and automation dependencies | Tenant settings; automation using human credentials | Enforcement status; postponement; workload identity migration | Postponed with no plan; scripts on human accounts |
| 12 | Analyze application registrations, service principals and consent | All applications | Owners, credentials and expiry, permissions, consent grants; consent policy | High-privilege applications with never-expiring secrets; user consent open |
| 13 | Test guest governance and tenant settings | All guests; settings | Inviter policy; expiry or review; log retention and export; risk policies | Thousands of stale guests; logs retained 30 days only |
| 14 | Test monitoring | Detection rules; alerts in the period | Rule inventory against the minimum set; log sources; alert handling sample | No detection of privileged group changes or replication requests |
Worked example: Lakeshore Bancorp’s two-forest directory
Lakeshore Bancorp, the nine-billion-dollar public regional bank with twenty-two internal auditors that appears across this site’s IT guides, runs an Active Directory forest built in 2009, a second forest inherited from a 2019 acquisition and connected by a two-way trust, and an Entra ID tenant synchronized from the main forest with password hash synchronization. The FY26 plan carried a 280-hour directory engagement, its first, performed by two IT auditors with a co-sourced identity specialist for 60 hours, with the infrastructure director as the main contact. The bank’s security function had run an assessment tool the previous year and filed the output.
The privileged population came to 26 Domain Admins in the main forest with nesting expanded, of whom 14 were daily-use accounts that read email and browsed the web, 4 were service accounts for backup, monitoring and a scanning tool, and 2 belonged to a vendor. Nobody used privileged access workstations, and the Protected Users group was empty. In Entra ID, 7 accounts held Global Administrator permanently, no Privileged Identity Management, and the two emergency access accounts existed but were included in the conditional access policies that required a device the accounts could not present, so they would not have worked. The hygiene queries found 1,900 of 9,400 computer objects and 640 user accounts inactive over 90 days and enabled, 118 accounts with service principal names of which 3 were Domain Admins with passwords aged over five years, a KRBTGT password last set in 2014, 212 group policies editable by an IT operations group of 31 people with no change tracking, and no LAPS deployment. The acquired forest’s trust had SID filtering disabled “for the migration,” which had finished in 2021, and the acquired forest had never been assessed. The synchronization server was a general-purpose virtual machine administered by the same 31-person group. In the tenant, 61 application registrations held credentials that never expired, 9 with directory-write or tenant-wide mail permissions, and user consent to applications was unrestricted. Monitoring covered failed logons and account lockouts; it did not cover privileged group changes, replication requests or service ticket bursts.
| Area | Result | Finding and rating |
|---|---|---|
| Privileged groups and tiering | 26 Domain Admins, 14 daily-use, 4 service, 2 vendor; no PAWs; Protected Users empty | Standing privilege and tiering (High) |
| Entra roles and emergency access | 7 permanent Global Administrators; no PIM; break-glass accounts blocked by conditional access | Cloud privilege and emergency access (High) |
| Hygiene | 640 stale enabled users, 1,900 stale computers, 3 privileged accounts with SPNs and old passwords, KRBTGT from 2014, no LAPS | Directory hygiene and Kerberos exposure (High) |
| Group policy | 212 policies editable by 31 people, no change tracking | Configuration change control (Medium) |
| Trusts | Two-way trust to the acquired forest, SID filtering disabled since 2019, acquired forest unassessed | Trust exposure (High) |
| Hybrid | Synchronization server administered as an ordinary VM by the 31 | Tier-zero treatment (High, combined with tiering) |
| Applications and consent | 61 never-expiring credentials, 9 high-privilege applications, open user consent | Application governance (Medium) |
| Monitoring | No detections for privileged changes, replication or ticket bursts | Detection coverage (Medium) |
The report rated the directory’s control environment as needing significant improvement, with the attack-path table above as its appendix so that the audit committee could see that the three findings rated High were, in combination, a complete path from any employee’s mailbox to the bank’s core systems. The remediation plan was sequenced by that path: reset the KRBTGT password twice and rotate the three privileged service accounts’ passwords in the first week; remove daily-use and vendor accounts from Domain Admins and issue separate administrative accounts within a month; enable SID filtering on the trust and schedule the acquired forest’s assessment; treat the synchronization server as tier zero; deploy LAPS and Privileged Identity Management within the quarter; fix the emergency access account exclusions the same day; and add the privileged-change and replication detections to the SIEM. Internal audit re-ran the hygiene queries after ninety days and reported the before-and-after numbers to the committee, which is the kind of follow-up the issue validation guide describes.
Common mistakes
- Treating the directory as IT plumbing. It is the control plane of every application control on the matrix; audit it as a system.
- Counting Domain Admins without expanding nesting. Groups inside groups hide most of the members.
- Ignoring the operator groups. Account Operators and Backup Operators are privileged too.
- Accepting emergency accounts that have never been tested. Test them, and check they are excluded from the policies that would block them.
- Skipping the Kerberos questions. SPNs on privileged accounts and an ancient KRBTGT password are the findings that matter most.
- Auditing group policy as documentation. It is production configuration; test permissions and change control.
- Forgetting the acquired forest. The trust makes its problems yours; test SID filtering and assess the domain.
- Treating the synchronization server as a server. It holds every password hash and a tenant credential; it is tier zero.
- Reading conditional access without the exclusions. The exclusions are the policy.
- Leaving applications and guests out. Over-privileged applications with never-expiring secrets are an attack path with no human in it.
Related guides
- How to audit identity and access management
- How to audit privileged access
- How to perform a user access review
- How to audit IT change management
- How to audit backups and recovery
- How to audit incident response
- How to audit patch and vulnerability management
- Auditing cybersecurity programs
- Auditing cloud computing
- SOX ITGC scoping
- Building the IT audit plan
- Issue validation
- IT & Cybersecurity Audit guides
Leave a Reply