09 Oct 2026 8 min read

Building IT Systems That Audit Themselves: Automation, Integration, and Zero Trust

I’ve been an IT engineer for a very long time, and if there’s one thing IT people know intimately, it’s audit. A lot of us don’t like it. But I’ve found that I actually enjoy audit.

Audit is the moment when I get to showcase the work. A good IT system is one that runs so efficiently you almost don’t see the effort behind it. Everything just works, like plumbing, you turn the tap, water comes out. All the complexities that went into delivering the water right to your bathroom and kitchen are completely hidden from you and frankly you don't care, you just expect the water to come out from the tap when you need it. It doesn’t look complicated and effort behind it are completely hidden from the user.

Audit is when you get the opportunity to pull back the curtain and talk about what it took to make that system run well.

Throughout my career, I’ve almost always worked under resource constraints. This almost usually means very little human resource. Scarcity brings out creativity and in my case, a lean team means leaning hard on automation. Automation does the everyday routine task allowing the team to do more strategic work.

One of the things automation also handles very well is audit.

Artifacts, Evidence, and System Integration

When auditors show up especially in environments pursuing ISO 27001 or PCI DSS they’re not looking for stories. They’re looking for artifacts and evidence. They want proof that controls are in place: evidence of user access reviews, proof of encryption, confirmation that policies are enforced. How complicated that process becomes depends entirely on how you’ve designed your systems.

This is where the idea of building inherently compliant systems comes in. i.e systems that have been built to run compliantly and not one that requires a lot of manual effort to proof compliance. And to build such a system, you have to stop seeing IT as a collection of separate tools. You have to see it as one central, integrated system. Every part has to talk to every other part. You cannot treat them as individually existent.

Explainer: Audit Artifacts and Evidence

In compliance frameworks like ISO 27001 (information security management) or PCI DSS (payment card data security), auditors don’t just take your word for it. They ask for artifacts documents, logs, screenshots, reports that serve as evidence a control is operating. Examples include access review logs, encryption status reports, or policy acknowledgment records. The goal is to prove the control exists and is effective. Automated systems generate these artifacts continuously instead of forcing teams to scramble before an audit.

The practical starting point is deep integration between systems. Your HR people management system must be tightly integrated with your identity and single sign-on (SSO) platform. User roles must map to specific applications on a need-to-know basis. When someone joins the company, their information is pushed to the identity management system ie Okta, Google Identity, JumpCloud, basic LDAP, or Microsoft Entra ID (the modern name for what used to be Azure Active Directory). From the HR system you pull the user’s role, department, and division, then use that data to assign them to the right groups, applications, and access roles. Those assignments are either pre-approved or defined by policy.

The Human Element and Identity Management

Technology integration alone isn’t enough. You also need integration of people. HR and IT have to work in sync. They can’t operate as two isolated departments, because humans ultimately define the system.

When that synergy exists, onboarding becomes seamless. A new hire is created in Human Resource Information System (HRIS), the identity system receives the data, groups and licenses are assigned automatically. If the person is in finance, their Microsoft 365 license is already there. Nobody has to do the assignment by hand. Everything works - beautifully if I might add.

When an auditor asks how a particular person has access to a system, you don’t dig through tickets. You show them the source of truth; the access matrix that defines who gets what, who approved it, and how that matrix is enforced in real time. And this is just looking at access control. Every other part of the environment works the same way when the systems are properly integrated.

Device Management in a Hybrid Workspace

Let’s talk about another core responsibility: device management. One of IT’s central jobs is managing the endpoint laptops you give to employees. We live in a complex hybrid world. Your company might be headquartered in Kuala Lumpur while employees sit in Paris or Kampala, Uganda. How do you tie all of that together?

You need device management systems Microsoft Intune, Jamf, or their equivalents working alongside your identity management system and your HR system. All of them have to be integrated if you want the environment to run autonomously.

In regulated industries like banking or finance, endpoints carry strict requirements: data must be encrypted at rest, anti-malware must be running, the firewall must be on, and the laptop must lock after a period of inactivity (the clear desk policy). If an employee leaves their laptop at a coffee shop, it should self-lock. These aren’t optional.

The first job of a device management system is to set those policies and enforce them. The harder problem is ensuring every laptop is actually being managed especially when people are scattered around the world and you can’t simply trust the user to do the right thing.

Explainer: Mobile Device Management (MDM)

MDM (or endpoint management) is software that lets IT configure, secure, and monitor company laptops, phones, and tablets from a central console. Instead of visiting every device, you push policies that turn on encryption, install required software, set lock timers, or block risky settings. Popular tools include Microsoft Intune and Jamf. In a hybrid workforce, MDM is how you keep devices consistent and compliant no matter where the employee is sitting

Zero Trust and Automated Enrollment

The central policy that solves this is Zero Trust. You don’t build systems that expect people to obey the rules. You build systems that require them to obey.

You can tell users, “Please encrypt your hard drive.” But we live in a hybrid workspace. Users aren’t under one roof, and even if they were, it doesn’t scale. Anything more than two or three employees and you need automation. Relying on users to complete enrollment themselves is fragile. Engineers might click through the screens easily. Less technical users will struggle, and suddenly an IT person is walking them through it one by one. That doesn’t scale.

What you need is enrollment that happens out of the box. When a laptop is delivered to someone in Singapore or Uganda, the moment they open it and power it on, the machine requires them to enroll before they can finish setup. Tools like Apple's Automated Device Enrollment (ADE) and Microsoft’s equivalent, (Autopilot + Intune) make this possible. The company is recognized by the operating system vendor and the OEM. Devices purchased through authorized channels are pre-registered to the organization.

This is the kind of foundational work IT should focus on. Buying laptops from random local shops or Computer Village might be fine if your risk tolerance is high. In a regulated industry, you don’t want that. You want an unbroken link between the OEM and your company through authorized distributors. That unbroken chain helps prevent supply chain attacks where a malicious actor sets up a spoof shop and ships you pre-compromised hardware.

Explainer: Zero Trust

Zero Trust is a security approach built on the principle “never trust, always verify.” Traditional networks often trusted anything inside the office network. Zero Trust assumes breach is possible and verifies every access request based on identity, device health, location, and other signals regardless of where the request comes from. It shifts security from the network perimeter to continuous verification of users and devices.

Explainer: Automated Device Enrollment (Apple Business Manager & equivalents)

When an organization enrolls in Apple Business Manager (or uses Windows Autopilot), devices purchased through authorized channels can be pre-assigned to the company’s MDM. On first boot, the device contacts Apple (or Microsoft) servers, learns it belongs to the company, and forces enrollment into MDM during setup. The user can’t skip it. This removes the need for IT to manually touch every laptop and prevents users from using the machine unmanaged.

Automating Compliance and Device Setup

When you buy through authorized channels, those laptops can be mapped to your MDM. On first power-on and internet connection, the setup screen requires the user to sign in with their corporate identity.

How does the MDM know who the employee is? You don’t maintain a separate user directory on the MDM. You connect the MDM to the Identity Management system, which is itself connected to the HR system. An employee in Kuala Lumpur opens the laptop, connects to the internet, and is prompted at the setup screen to log in with their corporate credentials.

That login does something important: the Identity Management system links the laptop to that specific user. The device is registered under their name. If the user then sets up biometrics or Touch ID, that biometric is also associated with the managed device. The laptop is now connected to the identity system, the MDM is connected to the identity system, and the device is known and registered. (Hold that thought we’ll come back to why it matters.)

Once enrollment completes, the device is automatically configured based on the user’s role. An engineer gets development tools, build environments, and the software they need. A salesperson gets Microsoft Office, Teams, and the collaboration tools required for their job. Compliance is also enforced automatically by the MDM: the firewall is turned on and locked so the user can’t disable it, encryption is enabled and can’t be rolled back, and every other required setting is applied. The laptop is compliant by default, and the user was forced to enroll it.

Enforcing Device Posture

You can have the most secure, most compliant company laptop in the world, but nothing stops a user from simply ignoring it and using their personal computer instead. That defeats the purpose.

Except, in this design, it doesn’t. Because the computer has been mapped to the user and identified by the identity management system, you can set Zero Trust policies that say: “This user can only log into this application from the laptop registered to their name, and only using the biometrics registered on that laptop.” You can go further: the laptop must be encrypted, the firewall must be on, it must be running the latest patches, and so on. Many platforms call this capability Device Posture.

You don’t ask or expect the user to comply. You require it for access. You can even go further by sending notifications to the user when their device falls out of compliance and with clear instruction on how to remediate or even auto-remediating the issue for them.

Explainer: Device Posture

Device Posture is a real-time check of a device’s security health before (and sometimes during) access is granted. It looks at signals such as whether disk encryption is enabled, the firewall is on, the operating system is patched, anti-malware is running, and the device is managed by the company MDM. In a Zero Trust model, identity alone is not enough, the device itself must prove it is safe. If the posture check fails, access can be blocked or limited until the issue is fixed.

Conclusion

This is how you build systems that are self-compliant. No employer will ever give you every resource you want. But when you can build systems that are deeply integrated, that work together as a cohesive unit to be compliant ab initio, audit stops being a scramble, and when the auditors come, you get to feel proud showing off the work.