> For the complete documentation index, see [llms.txt](https://engyon.gitbook.io/engyon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://engyon.gitbook.io/engyon/en/reference/entity-insights.md).
# Entity insights
On this screen, users can record processes, applications, and internal controls of the client and view interrelationships, so that the structural basis of the audit is in the audit.
### Entity overview
Via the navigation button Entity insights you model the client's organisation.
On this screen:
* [Processes recorded](/engyon/en/how-to-guides/risks/recording-processes-applications-and-internal-controls.md#adding-processes)
* [Applications linked to processes](/engyon/en/how-to-guides/risks/recording-processes-applications-and-internal-controls.md#adding-applications)
* [Internal controls (ICs) set up per system](/engyon/en/how-to-guides/risks/recording-processes-applications-and-internal-controls.md#creating-internal-controls-and-linking-itgcs)
* Audit units and financial statement line items connected to processes
Here the Auditor records the structural basis of the audit: how the organisation works, which IT systems are used, and where control takes place.
This work forms the foundation for the risk assessment, audit approach, and further development of the thread in the audit.
Under Views you will find the representation of all relationships between systems, processes, and internal controls.
### Entity relationships
For each process and transaction flow, it is necessary to understand how the client supports these with systems and data. The card shows the process, the linked application, the audit units, and the internal controls on that process.
Why is this important for an Auditor?
1. **Insight into control coverage and gaps** You see at a glance which controls are isolated (only a black block, no checkmarks) versus controls that have a broad effect across multiple systems. A control without overlap is a potential risk if it is removed.
2. **Rationalisation of your testing** If a control in Exact directly affects multiple controls in SAP BRIM, you may not need to test all SAP BRIM controls separately. This makes your audit more efficient and prevents double work.
3. **Exposing dependencies** Systems are rarely independent. If Exact manages the authorisations that also affect SAP BRIM, then a weakness in Exact is automatically a risk for SAP BRIM. Without this matrix, you might miss that connection.
4. **Substantiation of your reliance strategy** You can substantiate to the client and to your audit why you do or do not test certain controls, and which ones you rely on ("rely on") for your conclusion about other systems.
5. **Scope definition** The matrix helps in answering the question: which controls are in-scope for my audit? And: if I do not test one system, or only test it to a limited extent, what are the consequences for my total conclusion?
In short: this matrix makes the interconnectedness of internal controls visible across systems, which is essential for a risk-oriented and efficient IT audit.
