GRC Engineering Series: Let’s Design an Automated Enterprise Compliance System

Use Case: BusyBody Limited: Inside a Modern Enterprise

Imagine a company like BusyBody Limited — a large-scale enterprise with over 20,000 employees operating across multiple lines of business. Over the years, it has built deeply customized tooling to support its on-premise data centers, while gradually adopting a hybrid cloud model to scale and modernize its operations.

This isn’t a startup with endless venture capital. While teams are well-funded, budgets are still scrutinized, and every investment must justify its value. As a publicly traded organization generating over $10 billion in annual revenue, BusyBody Limited operates under constant pressure to balance growth, efficiency, and regulatory expectations.

To understand how such an organization functions, it’s important to look at how its core disciplines — security, compliance, and engineering — are structured.

Security: Decentralized but Specialized

Security in BusyBody Limited is not a single monolithic function — it’s a distributed ecosystem.

Rather than relying solely on a central security team, the organization embeds security capabilities within individual business units. Each unit operates with a degree of autonomy, maintaining its own capabilities across:

• Threat intelligence
• Incident detection and response
• Security architecture
• Compliance alignment
• Security reviews and assurance

This model allows security to scale with the business, but it also introduces challenges in consistency, visibility, and coordination across teams.

Compliance: Mature, Experienced, and Always Under Pressure

With its size and history, BusyBody Limited has a well-established compliance function that has undergone numerous regulatory and external audits.

The compliance organization is typically segmented into specialized teams, such as:

• Internal Controls: ensuring policies and controls are properly designed and implemented
• Audit Management : interfacing with external auditors and managing audit cycles
• Customer Trust & Assurance: responding to customer security questionnaires and due diligence requests

These teams are staffed with professionals who are highly experienced in navigating complex regulatory environments. However, they constantly face pressure — from evolving regulations, demanding auditors, and increasing customer expectations.

Engineering: Diverse, Autonomous, and Complex

Engineering at BusyBody Limited is far from uniform. It spans multiple functions, including:

• Product engineering
• DevOps and infrastructure
• Technical support
• Internal tooling development

Each team operates based on its own context — technology stack, business priorities, and operational model. As a result, there is significant variation in how key processes are handled, such as:

• Access management
• Change management
• Configuration deployment
• Vulnerability patching
• Privacy prioritization

While this autonomy enables speed and innovation, it also creates fragmentation, making it difficult to enforce consistent security and compliance practices across the organization.

The Reality: Constant Trade-offs

Despite having dedicated teams across security, compliance, audit, and legal, BusyBody Limited is in a constant balancing act. There is never enough budget, headcount, or cross-functional alignment to meet every demand.

This tension — between scale and control, autonomy and standardization, speed and assurance — is exactly where modern GRC engineering must step in.

Challenges faced by BusyBody Limited

Constantly evolving privacy/security compliance requirements

a) Keeping up with the dynamic nature of privacy and security compliance is a significant challenge. New regulations and updates to existing ones, require constant monitoring and adaptation.

b) Compliance gap analysis: Conducting regular assessments to identify any gaps in compliance and ensuring that existing systems and processes align with the latest requirements is a time-consuming but essential task.

c) Resource-intensive updates: Implementing changes to meet updated compliance standards often requires significant resources, both in terms of time and personnel, adding strain to the overall operational capacity of the organization.

Blindsided by engineering teams and their velocity

a) Communication barriers: There may be a lack of effective communication channels between the compliance team and engineering teams, leading to a lack of awareness about impending compliance requirements.

b) Integration challenges: Aligning compliance measures with the fast-paced development cycles of engineering teams can be challenging, with potential conflicts arising between the need for quick releases and the thoroughness required for compliance.

Culture and Buy-in push back

a) Integrating compliance tasks into the sprint cycles of engineering teams can be met with resistance as it may disrupt their established workflows and increase workload.

b) Perception of hindrance: Engineers may view compliance requirements as additional obstacles to their primary development goals, resulting in a negative attitude towards compliance teams.

c) Balancing act: Striking a balance between meeting compliance needs and maintaining the efficiency of engineering processes is an ongoing challenge, requiring constant negotiation and collaboration.

Interest by leadership due to regulatory fines

a) Reactive approach: The sudden interest in compliance due to regulatory fines may lead to a more reactive than proactive approach, potentially resulting in rushed implementations and overlooked details.

b) Shifting priorities: Leadership may prioritize compliance solely as a response to external pressure, without fully understanding the long-term benefits of a robust compliance strategy beyond avoiding penalties.

c) Education gap: There may be a need to educate leadership about the broader advantages of maintaining a strong compliance posture, such as building trust with customers, protecting the brand reputation, and ensuring long-term sustainability.

Audit Engine: Supporting architecture

Before we describe the audit engine, we need to have 2 things

• List of all controls
• List of all the possible applications, dependencies and tools that you need to pull data from during an audit (they will be used to develop integrations)

Lets go through each component

Controls Home (datastore) : This is a source of truth for all your controls. This could be a database with rows containing details of your controls. If you have a CCF, it becomes a lot easier to create this database. Below is an example schema

CREATE TABLE controls_home (
control_id SERIAL PRIMARY KEY,
control_name VARCHAR(255) NOT NULL,
control_area TEXT,
frameworks VARCHAR(100),
compliance_owner VARCHAR(100) NOT NULL
);

ChecksDB : This service contains all the information required for the team and the downstream services to perform checks. It provides a web interface for the compliance team to perform CRUD operations on the controls checks. There can be multiple checks for each control since there may be more than 1 check required to meet the objectives of the control. ChecksDB stores a history of all checks performed, maintains an audit log of the audits. Below is an example schema:

CREATE TABLE checks (
check_id SERIAL PRIMARY KEY,
control_id INT REFERENCES controls_home(control_id) ON DELETE CASCADE,
check_function TEXT NOT NULL,
frequency VARCHAR(50) NOT NULL
);

ScopeDB: This services contains details about the scope for an ongoing audit. During an audit when an auditor picks some samples this is where we can store them. The compliance team can interact with this service to add/edit/delete the sampling information for the audit. Below is an example schema:

CREATE TABLE ScopeDB (
audit_id SERIAL PRIMARY KEY,
audit_name VARCHAR(255) NOT NULL,
audit_start_date DATE NOT NULL,
audit_end_date DATE NOT NULL,
owner_name VARCHAR(100) NOT NULL,
sampling_details JSONB,
CONSTRAINT valid_dates CHECK (audit_start_date <= audit_end_date)
);

Audit Engine

The heart of the tooling, acting as the central hub that seamlessly connects and orchestrates various components. Its versatility is highlighted by its operation in two distinct modes: Continuous Compliance and Audit Period.

Continuous Compliance mode: In Continuous Compliance mode, the Audit Engine demonstrates its capability to maintain an ongoing assessment of the organization’s adherence to predefined controls. It accomplishes this by first reading checks from ChecksDB, ensuring that the latest compliance criteria are considered. The engine then efficiently pulls relevant data from integrations, incorporating information from various sources to provide a comprehensive view of the compliance landscape.

Its scalability is a key feature, adapting dynamically to the breadth and depth of controls in place. By creating insightful data-points, the Audit Engine delivers meaningful information to the compliance team, avoiding unnecessary noise and facilitating a focused approach to continuous compliance monitoring.

Audit Period Mode: During an audit period, the Audit Engine shifts its focus to the specific task of auditing samples identified in ScopeDB. It retrieves sampling data from ScopeDB, which serves as a repository for details about the depth of an ongoing audit. In conjunction with data from integrations, the engine meticulously examines each sample, utilizing validation functions represented in the check_function.

This process involves a thorough validation of the collected data against predefined criteria. If discrepancies or failures are detected, the engine generates alerts, prompting a re-sampling process to ensure accuracy and reliability. The culmination of this auditing effort is the generation of audit-ready reports, crafted to meet compliance standards. These reports are then made accessible to the compliance team through a user-friendly web interface, providing a transparent and efficient means for teams to review and consume the audit findings.

Integrations Middleware & Serializers

BusyBody Limited has a complicated infrastructure and tooling landscape. So there could be more than 1 tool doing a thing Example: Service-team-A provides access to its members using an SSO for Github, and use Kubernetes RBAC for giving granular access to certain pods within a cluster.

For the Access Management control, compliance should be fetching data from Github + K8s cluster for this in-scope service. In order to automate this, we should fetch the records from both systems.

# Github

# Who has access to the Github repo
GET /repos/:owner/:repo/collaborators
# Github: When was the access granted, re-accreditted
GET /repos/:owner/:repo/events

# K8s
GET /apis/rbac.authorization.k8s.io/v1/roles
GET /apis/rbac.authorization.k8s.io/v1/rolebindings
GET /apis/rbac.authorization.k8s.io/v1/clusterroles
GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings

# logging system
GET /k8s-audit/logs

After fetching data from both systems. It is ingested into the serializer. The serializer helps create data in a standardized format JSON

# from Github API

{
"user": {
"username": "john_doe",
"email": "[email protected]",
"full_name": "John Doe"
},
"access": [
{
"app_name": "github",
"access_granted": "2024-02-02T12:30:00Z",
"access_reaccredited": "2024-03-15T09:45:00Z",
"roles": ["collaborator", "reader"]
"metadata":
{
"repo_name": "example-repo",
}
}
]
}

# from K8s and Logging systems

{
"user": {
"username": "john_doe",
"email": "[email protected]",
"full_name": "John Doe"
},
"access": [
{
"app_name": "k8s_cluster",
"access_granted": "2024-02-21T12:30:00Z",
"access_reaccredited": "2024-03-15T09:45:00Z",
"metadata":
{
"namespace": "default"
"roles": ["cluster-admin", "view"]
}
}
]
}

The “Access Management Serializer,” “Vulnerability Management Serializer,” and “Change Management Serializer” are components designed to facilitate the integration and data exchange between specific systems within an organization. Each serializer is tailored to a particular domain, ensuring seamless communication and data flow for effective management of access, vulnerability, and change-related information.

Access Management Serializer:

• HR System
• SSO/LDAP Server
• Any other service maintaining user lists

Functionality:

• The Access Management Serializer serves as a mediator between the HR system, the Single Sign-On (SSO)/LDAP server, and potentially another service managing user lists.
• Utilizing APIs, the serializer fetches relevant data from the HR system, which typically contains employee information, roles, and access permissions.
• Similarly, it interacts with the SSO/LDAP server to retrieve user authentication and authorization details.
• If applicable, the serializer extends its functionality to fetch user data from any other designated service maintaining user lists.
• The fetched data is then structured and provided by the serializer for further processing, ensuring that access management systems are synchronized with the most up-to-date user information.

Vuln Management Serializer:

• Vuln Scanner
• Vuln Ticket Manager

Functionality:

• The Vuln Management Serializer facilitates communication between the vulnerability scanner and the vulnerability ticket manager.
• Through the use of APIs, the serializer retrieves vulnerability data from the scanner, which may include information about identified vulnerabilities, their severity, and affected systems.
• It also interacts with the vulnerability ticket manager, fetching details about the tickets created in response to identified vulnerabilities.

Change Management Serializer:

• Ticketing System
• Version Control System
• Continuous Integration/Continuous Deployment (CICD) System

Functionality:

• The Change Management Serializer acts as a bridge between the ticketing system, version control system, and CI/CD system.
• Leveraging APIs, the serializer fetches relevant data from the ticketing system, including details about change requests, approvals, and implementation timelines, roll-backs, etc
• It communicates with the version control system to obtain information regarding code changes, version history, and associated documentation.
• Additionally, the serializer interacts with the CICD system to access details about automated build and deployment processes. It also checks if the tests have passed for a particular deploy

Conclusion

In conclusion, this should prove that automated complaince is not only theory but a reality. the GRC practitioners of the now and future should watch out for this skill set, as there is becoming a trend of adoption of automation and AI

I hope this blog post gives a high-level understanding on how should the architecture for a GRC Automation tool look like! Feel free to connect with me if you want to talk/nerd out about such things.

• LinkedIn: https://www.linkedin.com/in/m49d4ch3lly
• Twitter: https://twitter.com/m49D4ch3lly
• GitHub: https://github.com/UFarouk10
• Gmail: [email protected]

GRC Engineering Series: Let’s Design an Automated Enterprise Compliance System was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.