Internal Audit and Compliance are, as we explained in another article on this blog, two functions with distinct roles within the Three Lines Model. But in day-to-day practice, more and more organizations want both to work on the same technology infrastructure: a shared risk map, a shared evidence base, a shared reporting language. The challenge is not technical, it is one of design: how to achieve that shared efficiency without Internal Audit losing the independence that justifies its existence as the third line. This article explains what a platform designed for both functions simultaneously must offer.
Why Internal Audit and Compliance increasingly share the same technology infrastructure
Combined assurance and the need for a shared risk map
As we explained when discussing the differences between both functions, the combined assurance model aims for Compliance and Internal Audit to work from a shared risk map, without that meaning they share conclusions or responsibilities. This is only feasible in practice if both functions have a platform that allows them to view the same risk universe from different angles, without forcing them to maintain parallel disconnected documents.
The risk of having disconnected systems between both functions
When Compliance manages its policies, training, and alerts in one tool, and Internal Audit documents its engagements in a completely different one, the typical result is duplicated effort: both functions end up requesting the same information from business areas, in different formats and at different points in the year, generating fatigue and confusion over who is asking for what and why.
How reference frameworks fit in (COSO, ISO 31000, COBIT)
Before discussing specific features, it is worth situating where the reference frameworks that Internal Audit, Compliance, and Internal Control already use fit in. These frameworks do not compete with each other: each covers a different angle of the same control system, and a good platform must be able to reflect all three simultaneously, without forcing the organization to choose just one.
COSO as the common language across Internal Control, Compliance, and Internal Audit
The COSO Internal Control framework, structured around its five components (control environment, risk assessment, control activities, information and communication, and monitoring activities), is in practice the language most shared by all three functions. Internal Control uses it to design its control matrix, Compliance uses it to frame its own regulatory controls within that same structure, and Internal Audit uses it as a reference for evaluating whether the internal control system as a whole is effective. A shared platform should allow tagging each control with its corresponding COSO component, so all three functions are literally speaking the same language when describing the same control.
ISO 31000 and shared risk management
ISO 31000 provides the risk management framework most commonly adopted by the Risk Management function, and consumed by both Compliance and Internal Audit to prioritize their own work. Its value within a shared platform lies in the risk taxonomy (likelihood, impact, risk appetite) that allows Compliance's risk map and Internal Audit's audit universe to be built on the same scale, even though each function applies it for a different purpose.
COBIT for technology and systems risks
When the risk being evaluated is technological in nature (IT governance, cybersecurity, access management), COBIT offers a more specific framework than generic COSO. Internal Audit commonly uses it as a reference when auditing systems, while Compliance uses it to the extent that regulatory obligations related to information security apply. A platform supporting multiple frameworks allows a single access control, for example, to be documented once and simultaneously linked to its COSO component and its corresponding COBIT control objective.
Why the platform must support multiple frameworks simultaneously, not just one
Forcing the organization to choose a single reference framework is usually a design mistake, because in practice each function already works with the framework that best suits its control subject. The right platform does not impose a framework; it allows mapping the same risk or control against multiple frameworks simultaneously, so the documentation work is done once and simultaneously serves an Internal Audit External Quality Assessment, a Compliance audit, and an ISO certification, without tripling the effort.
What a software covering internal audit and compliance management must offer
Shared risk and control map, with differentiated visibility by line
The platform must allow Compliance to document its own regulatory risks and associated controls, and Internal Audit to consult them when planning its work, without this implying that Internal Audit loses its independent judgment about what and how to evaluate. Visibility should be shared, but the ability to modify or approve must remain segregated by function.
Documentary traceability for both functions
Both an audit finding and a regulatory non-compliance identified by Compliance should be documentable to the same level of detail, evidence, and action plan follow-up, even though each is managed within its own function's workflow.
Policy management and training evidence
One of Compliance's most distinctive activities is managing the policy lifecycle: drafting, approval, communication, and training evidence. A shared platform should allow Internal Audit to consult that evidence directly when it needs to verify whether a policy has been properly communicated and trained, without having to request it separately.
Analytical capabilities for audit testing and Compliance monitoring
Compliance needs to continuously monitor alerts and transactions to detect non-compliance in near real time. Internal Audit needs, on the other hand, to run periodic analytical tests over complete populations to evaluate whether those monitoring controls are working well. Both needs can be served by the same analytical engine, applied with different frequency and purpose.
Differentiated reporting for the Audit Committee and Compliance Management
Each function's reporting has a different audience and a different language. The platform must generate differentiated views and reports from the same underlying data, without forcing either function to adapt its reporting to the format originally designed for the other.
How to prevent the platform from diluting Internal Audit's independence
Sharing technology should not mean sharing responsibilities. To preserve Internal Audit's independence within a shared platform, at least three design principles should be applied:
- Permission segregation by role, not just by function. Internal Audit should be able to view Compliance information but should not be able to edit or approve it, and vice versa.
- Audit trail within the platform itself. The system must record who created, modified, or closed each finding, control, or piece of evidence, so that traceability of who did what is as clear within the tool as it is on paper in the Three Lines Model.
- Separate approval workflows. An Internal Audit finding must follow its own approval circuit, distinct from the one followed by a Compliance-managed incident, even if both coexist in the same technology environment.
Practical criteria for choosing the right platform
| Criterion | What to verify |
|---|---|
| Access segregation | Configurable permissions by role and by function, not just by individual user |
| Methodological flexibility | Allows reflecting Internal Audit's own criticality scale and Compliance's own regulatory taxonomy, without forcing a single model |
| Analytical capability | Supports both continuous monitoring and periodic testing over the same data source |
| Document management | Centralizes policies, training evidence, and workpapers in a single but segregated repository |
| Configurable reporting | Generates different views for the Audit Committee and Compliance Management from the same underlying data |
| Internal traceability | Records each action taken within the platform in an immutable audit trail |
| Multi-framework support | Allows mapping the same control against multiple reference frameworks (COSO, ISO 31000, COBIT) without duplicating documentation |
Common mistakes when implementing a shared platform
- Configuring a single approval workflow for both functions. This creates confusion over responsibilities and may give the impression that both functions are validating the same thing, when in reality they are evaluating different things.
- Giving Compliance edit permissions over Internal Audit findings. Even if the intent is simply to facilitate follow-up, this compromises the integrity and independence of the audit record.
- Forcing Internal Audit to adopt the risk taxonomy originally designed for Compliance. Each function needs its own risk language, even if both languages need to be relatable within the same platform.
- Not defining from the outset who administers what within the system. Without clear governance over platform administration, both functions end up depending on a third team (typically IT) to resolve configuration conflicts that should have been anticipated.
Key control point: if your organization already has a combined assurance map but Internal Audit and Compliance are still working in different tools, most of the benefit of that combined model is not yet materializing in practice.
A GRC and audit management platform designed to support multiple functions simultaneously, with segregated permissions and its own traceability for each, allows capturing that benefit without compromising the independence that distinguishes Internal Audit from the other lines of defense.
Checklist for evaluating a shared platform
- Does it allow segregating edit and approval permissions between Internal Audit and Compliance?
- Does it maintain an internal audit trail recording who performed each action within the system?
- Does it support different risk taxonomies for each function without forcing a single model?
- Does it generate differentiated reporting for the Audit Committee and Compliance Management?
- Does it centralize documentary and training evidence in a way that is accessible to both functions?
- Is there clear governance over who administers the platform's configuration?
- Does it allow mapping the same risk or control against multiple reference frameworks (COSO, ISO 31000, COBIT) without duplicating documentation?
Conclusion
Sharing technology between Internal Audit and Compliance can deliver real efficiency, as long as the chosen platform respects the independence boundary that separates the third line from the second. The goal is not for both functions to work the same way, but to work from the same information base without losing what makes them distinct: one designs, monitors, and acts continuously; the other evaluates, independently, whether that entire system is working as it should.
FAQs
1. ¿Cómo ayuda un software de auditoría interna al cumplimiento normativo?
Centralizando auditorías, controles y evidencias, mejorando la trazabilidad y asegurando consistencia metodológica.
2. ¿Es compatible un software de auditoría interna con ISO y COSO?
Sí, siempre que permita mapear riesgos, controles, auditorías y acciones correctivas de forma estructurada.
3. ¿Qué exige el IIA en términos de documentación?
Documentación suficiente, consistente y trazable que respalde conclusiones y recomendaciones de auditoría.
4. ¿El software reemplaza el criterio del auditor?
No. El software apoya el proceso, pero el juicio profesional sigue siendo responsabilidad del auditor interno.
5. ¿Qué riesgos existen sin un software de auditoría interna?
Falta de trazabilidad, inconsistencias metodológicas, dificultad para demostrar cumplimiento y mayor exposición a observaciones regulatorias.