Imagine a company like BusyBody Limited\u200a\u2014\u200aa 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.<\/p>\n
This isn\u2019t 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.<\/p>\n
To understand how such an organization functions, it\u2019s important to look at how its core disciplines\u200a\u2014\u200asecurity, compliance, and engineering\u200a\u2014\u200aare structured.<\/p>\n
Security in BusyBody Limited is not a single monolithic function\u200a\u2014\u200ait\u2019s a distributed ecosystem.<\/p>\n
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:<\/p>\n
Threat intelligenceIncident detection and\u00a0responseSecurity architectureCompliance alignmentSecurity reviews and assurance<\/p>\n
This model allows security to scale with the business, but it also introduces challenges in consistency, visibility, and coordination across\u00a0teams.<\/p>\n
With its size and history, BusyBody Limited has a well-established compliance function that has undergone numerous regulatory and external\u00a0audits.<\/p>\n
The compliance organization is typically segmented into specialized teams, such\u00a0as:<\/p>\n
Internal Controls: <\/strong>ensuring policies and controls are properly designed and implementedAudit Management<\/strong>\u00a0: interfacing with external auditors and managing audit\u00a0cyclesCustomer Trust & Assurance: <\/strong>responding to customer security questionnaires and due diligence requests<\/p>\n These teams are staffed with professionals who are highly experienced in navigating complex regulatory environments. However, they constantly face pressure\u200a\u2014\u200afrom evolving regulations, demanding auditors, and increasing customer expectations.<\/p>\n Engineering at BusyBody Limited is far from uniform. It spans multiple functions, including:<\/p>\n Product engineeringDevOps and infrastructureTechnical supportInternal tooling development<\/p>\n Each team operates based on its own context\u200a\u2014\u200atechnology stack, business priorities, and operational model. As a result, there is significant variation in how key processes are handled, such\u00a0as:<\/p>\n Access managementChange managementConfiguration deploymentVulnerability patchingPrivacy prioritization<\/p>\n While this autonomy enables speed and innovation, it also creates fragmentation, making it difficult to enforce consistent security and compliance practices across the organization.<\/p>\n 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\u00a0demand.<\/p>\n This tension\u200a\u2014\u200abetween scale and control, autonomy and standardization, speed and assurance\u200a\u2014\u200ais exactly where modern GRC engineering must step\u00a0in.<\/p>\n Constantly evolving privacy\/security compliance requirements<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Blindsided by engineering teams and their\u00a0velocity<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n Culture and Buy-in push\u00a0back<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Interest by leadership due to regulatory fines<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Before we describe the audit engine, we need to have 2\u00a0things<\/p>\n List of all\u00a0controlsList 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)<\/p>\n Lets go through each component<\/p>\n Controls Home (datastore)\u00a0: <\/strong>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\u00a0schema<\/p>\n CREATE TABLE controls_home ( ChecksDB\u00a0<\/strong>: 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. <\/em>Below is an example\u00a0schema:<\/p>\n CREATE TABLE checks ( ScopeDB<\/strong>: This services contains details about the scope for an ongoing <\/em>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\u00a0schema:<\/p>\n CREATE TABLE ScopeDB ( Audit Engine<\/strong><\/p>\n 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\u00a0Period.<\/p>\n Continuous Compliance mode: <\/strong>In Continuous Compliance mode, the Audit Engine demonstrates its capability to maintain an ongoing assessment of the organization\u2019s 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.<\/p>\n 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.<\/p>\n Audit Period Mode: <\/strong>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.<\/p>\n 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.<\/p>\n Integrations Middleware & Serializers<\/strong><\/p>\n 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\u00a0cluster.<\/em><\/p>\n 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\u00a0systems.<\/p>\n # Github# Who has access to the Github repo After fetching data from both systems. It is ingested into the serializer. The serializer helps create data in a standardized format\u00a0JSON<\/p>\n # from Github API{ The \u201cAccess Management Serializer,\u201d \u201cVulnerability Management Serializer,\u201d and \u201cChange Management Serializer\u201d 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.<\/p>\n Access Management Serializer:<\/strong><\/p>\n HR SystemSSO\/LDAP ServerAny other service maintaining user\u00a0lists<\/p>\n Functionality:<\/p>\n 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\u00a0lists.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\u00a0lists.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.<\/p>\n Vuln Management Serializer:<\/strong><\/p>\n Vuln ScannerVuln Ticket\u00a0Manager<\/p>\n Functionality:<\/p>\n The Vuln Management Serializer facilitates communication between the vulnerability scanner and the vulnerability ticket\u00a0manager.Through the use of APIs, the serializer retrieves vulnerability data from the scanner, which may include information about identified vulnerabilities, their severity, and affected\u00a0systems.It also interacts with the vulnerability ticket manager, fetching details about the tickets created in response to identified vulnerabilities.<\/p>\n Change Management Serializer:<\/strong><\/p>\n Ticketing SystemVersion Control\u00a0SystemContinuous Integration\/Continuous Deployment (CICD)\u00a0System<\/p>\n Functionality:<\/p>\n The Change Management Serializer acts as a bridge between the ticketing system, version control system, and CI\/CD\u00a0system.Leveraging APIs, the serializer fetches relevant data from the ticketing system, including details about change requests, approvals, and implementation timelines, roll-backs, etcIt 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<\/p>\n 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\u00a0AI<\/p>\n 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\u00a0things.<\/p>\n LinkedIn: <\/strong>https:\/\/www.linkedin.com\/in\/m49d4ch3lly<\/strong><\/a>Twitter: <\/strong>https:\/\/twitter.com\/m49D4ch3lly<\/strong><\/a>GitHub: <\/strong>https:\/\/github.com\/UFarouk10<\/strong><\/a>Gmail: Umarfarouk037@gmail.com<\/strong><\/p>\n GRC Engineering Series: Let\u2019s Design an Automated Enterprise Compliance System<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Use Case: BusyBody Limited: Inside a Modern Enterprise Imagine a company like BusyBody Limited\u200a\u2014\u200aa 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 […]<\/p>\n","protected":false},"author":0,"featured_media":147581,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-147580","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/147580"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=147580"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/147580\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/147581"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=147580"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=147580"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=147580"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Engineering: Diverse, Autonomous, and\u00a0Complex<\/h3>\n
The Reality: Constant Trade-offs<\/h3>\n
Challenges faced by BusyBody\u00a0Limited<\/h3>\n
Audit Engine: Supporting architecture<\/h3>\n
control_id SERIAL PRIMARY KEY,
control_name VARCHAR(255) NOT NULL,
control_area TEXT,
frameworks VARCHAR(100),
compliance_owner VARCHAR(100) NOT NULL
);<\/p>\n
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
);<\/p>\n
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)
);<\/p>\n
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<\/p>\n
“user”: {
“username”: “john_doe”,
“email”: “john.doe@example.com”,
“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”: “john.doe@example.com”,
“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”]
}
}
]
}<\/p>\nConclusion<\/h3>\n