House of Trust x Scrut Automation

Why We chose This GRC Platform as the Backbone of Our Compliance Operations

At House of Trust, we implement GRC from day one. It is not optional, it is not something we add later once the basics are in place. It is the foundation everything else is built on. Over the past years we have evaluated, tested and worked with multiple platforms. Scrut Automation is the one we kept coming back to, and eventually the one we built our practice around. This post explains why, and what that means for the organisations we work with across Europe.

The Problem We Were Trying to Solve

Most organisations we work with are not dealing with just one compliance framework. They are running ISO 27001 alongside NEN 7510. They have SOC 2 requirements from US-based customers while also needing to demonstrate BIO compliance for Dutch public sector contracts. They are managing multiple frameworks, multiple audit cycles and multiple sets of evidence, often across a team that does not have the bandwidth to handle that complexity manually.

The traditional answer to this problem is spreadsheets. A risk register in Excel. A control list in another file. Evidence collected by email. Policies stored in a shared folder that nobody can find. Vendor agreements signed once and never reviewed again.

We have seen this pattern in organisations of every size. And we have seen what happens when an auditor arrives and the evidence is scattered, outdated or simply missing. The result is last-minute stress, gaps that should have been closed months ago, and a compliance programme that exists on paper but not in practice.

A GRC platform solves this. But not every GRC platform solves it well. The reason we chose Scrut Automation specifically comes down to one core feature: the Unified Controls Framework.

What is the Unified Controls Framework?

The UCF is Scrut's answer to the multi-framework problem, and it is the feature that, because it is implemented so well, truly sets it apart from other platforms we have worked with.

The concept is straightforward. Instead of treating every compliance standard as a separate silo that needs its own controls, its own evidence and its own policies, the UCF places a single unified control set at the centre of everything. Framework requirements from ISO 27001, NEN 7510, SOC 2, PCI DSS, NIST AI RMF, BIO and others all map into this shared control library.

The hierarchy works in three layers. At the top sit the Framework Requirements, the specific clauses and controls that each standard demands. In the middle sits the UCF, the centralised control set that absorbs and maps those requirements. At the bottom, each control connects to Policies, Evidence and automated Tests.

The practical consequence of this architecture is significant. When you implement a control to satisfy an ISO 27001 requirement, that same control automatically contributes to your NEN 7510 compliance posture, and to any other framework that shares that requirement. You are not duplicating work. You are not maintaining parallel control sets. You are building once and getting credit across every framework you are working towards.

For organisations managing two or more frameworks simultaneously, this alone removes a substantial amount of manual effort from the compliance programme.

Controls, Statuses and Function Grouping

Within the UCF, every control carries a status: Compliant, Non-Compliant or Not Applicable. A control is considered compliant when all associated artifacts, meaning the relevant policy, evidence and automated test, are in place and up to date. If any artifact is missing or fails, the control is marked non-compliant. Controls that fall outside the defined scope of an organisation can be marked not applicable.

This sounds simple, but the operational value is considerable. At any point in time, the platform gives a complete and accurate picture of where the organisation stands. Not a snapshot taken during an audit, but a live view that updates as evidence is collected, policies are published and tests are run.

Controls are also grouped by function, following the Identify, Protect, Detect, Respond and Recover model. This grouping makes it possible to assess not just whether a control is technically compliant, but what role it plays in the broader security programme. An organisation that is strong on Protect but weak on Detect and Respond has a different risk profile than one where those functions are balanced, and the platform makes that visible immediately.

What the Compliance Dashboard Shows

The compliance dashboard in Scrut gives a real-time overview of the organisation's compliance posture across all active frameworks. The main indicator is the overall compliance percentage, which reflects the proportion of in-scope controls that are currently marked compliant. Alongside that, the dashboard shows policy coverage and the percentage of automated tests passing.

For organisations working across multiple frameworks, the by-framework view is particularly useful. It shows readiness per standard, making it immediately clear where gaps exist and which frameworks need attention. This is the view that changes the conversation with management. Instead of a qualitative report written once a year, leadership has a live dashboard they can check at any time.

Risk Management That Actually Moves

One of the most common failures we see in compliance programmes is risk management that is static. A risk assessment is done, risks are documented, and then nothing changes until the next assessment cycle. In the meantime, the actual threat landscape shifts, new vendors are onboarded, new systems are deployed, and the risk register becomes increasingly disconnected from reality.

Scrut's risk management module is built around continuous movement. The risk trend dashboard shows how risks are progressing over time: how many are open, how many are in treatment and how many have been closed. This is not a reporting feature. It is a management tool that shows whether the security programme is actually making progress or just generating paperwork.

Risks in Scrut can be identified manually, through AI analysis of uploaded documents such as vendor contracts and SOC 2 reports, and through integrations with cloud environments and vulnerability scanners. Once identified, risks are assessed, treated and tracked through to closure, with every action logged and auditable.

For the organisations we manage through our ISaaS practice, this means we can demonstrate to management and auditors not just that risks exist, but that they are being actively managed and resolved.

Vendor Management in One Place

Vendor risk is one of the areas where compliance programmes most commonly fall short. Vendors are onboarded, agreements are signed, and then the relationship is never reviewed again from a security perspective. Meanwhile, those vendors may have access to sensitive systems, process personal data or provide critical infrastructure that the organisation depends on.

Scrut's vendor management module integrates directly with the risk register.

Vendor risks are not managed separately, they are part of the same risk landscape as internal risks. New applications connected via SSO are automatically surfaced in the vendor list. AI analysis of SOC 2 certificates and security questionnaires identifies potential risks before they become problems. Automated reminders flag certificates approaching expiry and trigger review workflows before deadlines are missed.

For our clients, this means vendor management is no longer a separate spreadsheet that someone updates once a year. It is a continuous, connected part of the compliance programme.

Audit Readiness as a Default State

The goal of everything described above is to make audit readiness the default state of the organisation, not something that is assembled in the weeks before an auditor arrives.

When evidence is collected continuously, when controls are monitored in real time, when risks are actively managed and vendors are reviewed on schedule, the audit becomes a confirmation of what is already known rather than a discovery exercise. Auditors get controlled access to the platform. Evidence is centralised. Non-conformities are recorded directly, linked to controls and connected to corrective actions.

This is the shift that a well-implemented GRC platform makes possible. Not just better compliance, but a fundamentally different relationship with the audit process.

Why We Partner with Scrut for the European Market

We became an official partner of Scrut Automation for the European market because it is the platform that best fits the way we work and the needs of the organisations we serve. It handles the complexity of multiple frameworks without requiring multiple tools. It makes compliance visible and continuous rather than periodic and reactive. And it scales from small organisations running a single framework to larger clients managing several simultaneously.

For our ISaaS practice, where we manage ISMSs on behalf of clients, Scrut is the platform where everything lives: risk registers, evidence, policies, vendor records, audit trails and management reports. It is the single source of truth that makes the whole service possible.

For organisations that want to manage their own compliance programme, we can implement and configure Scrut, build the right framework structure and train the team to maintain it independently.

If you are evaluating GRC tooling, looking to move away from spreadsheets, or want to understand how the Unified Controls Framework could work for your specific combination of standards, reach out. We are happy to show you what a properly configured Scrut environment looks like in practice.