Staying compliant – What you need to know

Staying on top of compliance has become essential for businesses today. With tougher data laws and headline-making breaches happening regularly, companies can't risk taking a casual approach to following regulations. And it goes beyond just avoiding penalties. Strong compliance practices protect your customers' trust and your company's reputation.

In this article we examine the key elements of compliance that should be prioritized, from data quality and change management to audit logs and access control. We also explore how picking the right authorization system can strengthen your compliance efforts.

TL;DR - Compliance needs to be woven into your operations from the start, not tackled on later. And having the right tools can make the whole process smoother.

The importance of compliance

Regulatory compliance is non-negotiable. Governments and industry bodies worldwide have introduced frameworks such as GDPR in Europe, HIPAA for healthcare, SOC 2 for service organizations, PCI DSS for payment data, financial regulations for banks, and more. They all carry serious penalties for violations. Failure to comply can result in regulatory investigations, serious fines, lawsuits, and damage to customer trust.

For example, EU authorities have not hesitated to levy massive fines under GDPR: British Airways faced a fine of £183 million (about $230M) after a 2018 data breach for failing to safeguard customer data​. In another case, France’s data protection regulator hit Google, with a €50 million fine for insufficient transparency and consent practices​. It’s clear that regulators will use their full power to punish non-compliance.

The financial industry offers similar cautionary tales. In 2016, Morgan Stanley was fined $1 million by the U.S. SEC after a wealth management employee stole data on 730,000 clients. The SEC found the firm “failed to adopt written policies and procedures reasonably designed to protect customer data,” enabling the insider to access and transfer client records to his personal server (which was then hacked). And in 2020, Capital One was ordered to pay an $80 million penalty to U.S. banking regulators following a breach that exposed 106 million customer records. Regulators cited the bank for failing to identify and manage cloud migration risks and lacking sufficient security controls.

In healthcare, Anthem Inc. suffered a 78 million record breach and agreed to a record $16 million HIPAA settlement, after investigators found multiple compliance failures leading to unauthorized access to patient data.

These cases make one thing absolutely clear: non-compliance not only incurs fines but also remediation costs, legal settlements, and PR nightmares.

Compliance failures are costly beyond the fines themselves. A study by the Ponemon Institute found that, on average, non-compliance costs companies about 2.7 times more than meeting compliance requirements in the first place. This figure factors in business disruption, revenue losses, and reputational damage.

In short, the cost of compliance is far lower than the cost of non-compliance, and the stakes encompass financial stability, executive careers, and brand trust.

Data quality as a compliance pillar

High-quality data governance is a foundation of compliance. Regulations like GDPR and HIPAA require organizations to know what data they have, ensure its accuracy, and handle it responsibly. Data quality refers to characteristics such as accuracy, completeness, timeliness, consistency, uniqueness, and appropriate granularity of the data an organization uses.

If your data is unreliable, any compliance measures built on that data can crumble. For instance, access control decisions, audit reports, and privacy protections are only as good as the data supporting them. IBM identifies six core pillars of data quality, and ways to improve each.

Pillar	Description
Accuracy	Data should reflect real-world values with minimal errors or wrong entries. In a compliance context, inaccurate data (e.g. an incorrect user role or an outdated permission) could lead to unauthorized access. Improving accuracy might involve validation rules that prevent invalid data from entering systems.
Completeness	All necessary data should be present. Missing or blank values can undermine decision-making. For example, if an employee’s department field is blank, an access policy might not apply correctly. Ensuring completeness could mean merging multiple data sources or filling gaps with reference data.
Timeliness (Currency)	Data must be up-to-date and available when needed. Compliance often demands timely updates, such as promptly revoking access when an employee leaves. If revocations or modifications are delayed, you risk former users retaining access to sensitive systems. Keeping data current through real-time updates or periodic refreshes is essential.
Consistency	Data should be uniform across different systems and reports. Inconsistencies (e.g. two systems disagreeing on a user’s clearance level) create confusion and compliance gaps. Establishing standard formats, definitions, and synchronization processes helps maintain consistency.
Uniqueness	There should be no duplicate records for the same entity. Duplicates can lead to oversights like a user having two active accounts when policy expects one. Eliminating duplicate entries (e.g. via de-duplication tools) ensures that monitoring and access controls apply singularly to each real person or object.
Granularity (Relevance)	Data must have the appropriate level of detail for its purpose. Excessively granular data can be hard to manage, while overly coarse data may not support specific compliance needs. For example, classifying data with the right sensitivity level is a granularity issue – too broad a classification might grant overly broad access. Striking the right balance lets you enforce fine-grained authorization where needed while keeping oversight manageable.

Effective data governance policies tie these pillars together. By governing how data is collected, stored, and updated, you create a single source of truth that compliance controls can trust. For instance, maintaining accurate HR records of user roles and status is critical to an access control system: if HR data says an employee is active when they’ve left, you could violate both security policy and laws like HIPAA or GDPR by keeping their access live. Data quality and integrity (preventing unauthorized changes to data) are also linked - robust access controls, encryption, and backup processes preserve the integrity of data as it’s updated.

In summary, clean, consistent, and current data is a pillar of compliance. It underpins everything from privacy consent management to who is authorized to see which records. Investing in data quality yields compliance dividends: you can more readily demonstrate to auditors that you know your data and control it properly.

Why Change Advisory Boards (CAB) matter in compliance

Change is inevitable in tech systems – new software releases, configuration updates, onboarding of vendors or partners. But uncontrolled change is a major compliance and security risk. This is where a Change Advisory Board (CAB) or similar change management process becomes vital.

A CAB formally reviews and approves changes to systems and applications, ensuring that every change is evaluated for potential risks, tested in advance, and backed by a rollback plan if something goes wrong. In the context of compliance, structured change management prevents scenarios where a well-intentioned update accidentally disables a security control or opens a loophole that violates policy. Many compliance frameworks (from ISO 27001 to SOC 2) include requirements for change management precisely because poor change control can lead directly to breaches.

History has shown that the lack of a strong change management process can be disastrous. Case in point: the Target breach of 2013. Target’s security team knew third-party vendors (like the HVAC contractor that had network access) posed risks, but the organization did not enforce adequate controls or training around that knowledge. On a busy Black Friday weekend, attackers exploited a vendor’s credentials to penetrate Target’s network, then installed malware on point-of-sale systems to harvest customer card data. One major reason this breach succeeded was the absence of a robust change management and vendor governance program – there was no effective process to apply security updates or network segmentation that could have mitigated the attack. The result: over 40 million payment cards and 70 million customer records were stolen, and Target had to pay out around $202 million in settlements, legal fees, and other costs. A proper CAB process might have prompted stricter third-party access controls or earlier action on detected anomalies, potentially preventing the incident or lessening its impact.

Another famous example highlighting change management failure is the Knight Capital incident from 2012, in the financial sector. Knight Capital deployed new trading software to production without fully testing it or having a rollback plan. A hidden software glitch went live and in 45 minutes caused erratic trades totaling $440 million – bankrupting the firm nearly overnight. An analysis later pointed to poor configuration management and lack of a strong Change Control Board: there was no thorough vetting of the deployment, and no kill-switch or rollback procedure was in place and tested. As one observer noted, a good change review board would have ensured a fallback plan was “paramount” and that errors would not derail the business. In Knight’s case, the disaster led to regulatory scrutiny and new rules (U.S. regulators considered requiring a trading “kill switch” after this event). An extreme but instructive lesson.

So we can see that CABs do matter for compliance. A CAB brings together cross-functional experts (operations, security, compliance, development) to scrutinise proposed changes. They ask:

• Does this change introduce a security weakness or break compliance control?
• Has it been tested in a staging environment?
• Is there a rollback plan if production issues occur?

By demanding these answers before approval, the CAB reduces the chance of a change causing a compliance failure. It also ensures documentation, meaning that each change has a record of what was done and who approved it, which is gold in compliance audits. When auditors ask for evidence of controlled change processes (as required by Sarbanes-Oxley IT controls or ISO 27001), a well-run CAB provides it. Conversely, if an organization cannot demonstrate change discipline, it raises red flags.

Here’s how Facebook (now Meta) introduced improved change management processes. In 2018, the company faced a massive compliance and trust crisis with the Cambridge Analytica scandal, where user data was misused, violating a 2012 FTC consent order. The U.S. Federal Trade Commission levied a record $5 billion fine and demanded changes. As part of the 2019 FTC settlement, Facebook established an independent Privacy Committee at the board of directors level, functioning much like a Change Advisory Board focused on privacy impacts. This board-level CAB meets quarterly to review major product changes and data practices, and it is informed by an independent privacy assessor who continually audits Facebook’s privacy program. Facebook also created internal compliance teams and designated Privacy Compliance Officers who must sign off on high-risk changes. Every new feature or update now undergoes a rigorous privacy review process: identifying potential risks, documenting how those risks are addressed, and requiring approvals at multiple levels (engineers, privacy experts, legal, and the new privacy CAB at the board) before rollout.

In summary, structured change management is a frontline defense for compliance. It turns the adage “move fast and break things” on its head. In regulated industries, you need to move carefully and fix things before they break compliance. Every production change is an opportunity to either bolster your security posture or accidentally undermine it. A CAB makes sure it’s the former.

The necessity of audit logs

When it comes to compliance - if it’s not documented, it didn’t happen. This is especially true for security events and access to sensitive data. Audit logs – detailed records of who did what and when in your systems, are indispensable for both proving compliance and detecting violations.

Many regulations explicitly mandate logging. For example, the HIPAA Security Rule requires covered entities to implement audit controls to record and examine activity in information systems containing electronic protected health information. Financial regulators insist on logs of transactions and system access (the SEC’s Regulation S-P Safeguards Rule and SOX IT controls demand evidence of proper oversight). PCI DSS (for payment card security) has an entire requirement around tracking and monitoring all access to cardholder data. Without comprehensive logs, an organization cannot demonstrate to auditors that its controls are functioning, nor can it adequately investigate and respond to incidents.

Audit logs serve three critical compliance functions: accountability, forensic evidence, and anomaly detection.

• Accountability means every privileged action (like granting access rights, viewing confidential records, or changing system configurations) is traceable to an individual user. This discourages negligent or malicious behaviour. If someone knows their actions are being logged and reviewed, they are far less likely to attempt unauthorized activities. And, it holds technical stakeholders accountable for maintaining air-tight security.
• Forensic evidence comes into play when something does go wrong. Whether it’s a suspected breach, fraud, or data leak. Logs provide the trail of events for investigators to determine the scope of an incident and its root cause. Let’s imagine a scenario where sensitive records are leaked to the public: without logs, you may have no idea if an insider accessed those records before the leak or if an external attacker did so. Regulators, too, will ask for logs during incident investigations; failure to produce them suggests a lack of control.
• Finally, anomaly detection: by monitoring logs in real time (or near real time), organizations can spot unusual patterns. For example, a user account accessing an unusually large number of records, or login attempts at odd hours. These could be early signs of a breach or misuse, allowing the company to respond before damage is done.

Real-world compliance failures highlight the necessity of logs. A notable case is the $5.5 million HIPAA settlement with Memorial Healthcare Systems (MHS) in 2017. MHS had policies on paper to govern workforce access to patient data, but in practice it failed to enforce them. Over the course of a year, the login credentials of a former employee of an affiliated clinic were not terminated, and were used to access hospital patient records on a daily basis without detection, affecting over 100,000 individuals. Why did it go unnoticed? Because MHS failed to regularly review their IT system’s audit logs, despite this risk being identified in prior risk analyses.

As the HHS Office for Civil Rights noted, “Organizations must implement audit controls and review audit logs regularly. As this case shows, a lack of access controls and regular review of audit logs helps hackers or malevolent insiders to cover their electronic tracks”. In other words, without vigilant log monitoring, MHS had no idea data was being siphoned illicitly, which made a bad breach far worse. The fine and corrective action plan that followed sent a clear message to the healthcare industry about log oversight.

Poor logging practices have consequences in other sectors as well. Imagine a financial trading firm where an unauthorized trade is executed. If you can’t trace who placed the trade due to missing logs, you might violate SEC requirements and be unable to prove you didn’t facilitate fraud. Or consider GDPR’s accountability principle: an EU company suffering a data breach must demonstrate the security measures it had in place. If you lack log records around that breach, regulators could determine you didn’t meet the “appropriate security” standard, leading to fines. In many GDPR fines, the inability to fully reconstruct events or detect the breach promptly has been cited as an aggravating factor.

Comprehensive audit logs mitigate these risks. Best practices include: logging all authentication and authorization events, admin actions, data exports or deletions, and any changes to security settings. Just as important is protecting and retaining those logs. They should be tamper-proof (often achieved by sending to a secure, centralized logging system) and kept as long as regulations require (e.g. some financial records must be kept 7 years or more). Regular review is key: whether through automated alerting or manual audits, someone should be watching the watchers. Modern security information and event management (SIEM) tools can aggregate logs and flag anomalies for investigation. From a compliance perspective, audit logs are your safety net and evidence trail. They demonstrate to auditors that controls are in place and provide the backbone for any incident response.

Iterative testing frameworks in access control

Strong policies and controls on paper don’t guarantee real-world compliance – you must test them. In software development, we use testing frameworks to catch bugs; similarly, in authorization and access control, testing frameworks are crucial to catch policy misconfigurations or unintended consequences before they hit production.

This is especially true in highly regulated industries like fintech and healthcare, where a single mistake in access control could lead to a reportable breach or regulatory violation. For example, a fintech application might enforce that traders cannot see clients’ personal data beyond what’s necessary. If there is a bug or misconfiguration in that rule, a trader might inadvertently access sensitive client info, violating privacy laws and financial regulations about information barriers. The time to discover such a flaw is in pre-production testing – not after an auditor or journalist does.

Access control policies can be complex, often combining role-based rules, attribute-based conditions, and exceptions. It’s easy for a subtle logic error or oversight to create a hole. An iterative testing framework for authorization means you continuously validate that your policies are doing what you expect. This can involve automated policy tests (similar to unit tests) that simulate various user roles and actions to ensure the outcome (allow vs. deny) matches the requirement. It can also involve staging environments where new policies are trialled against real scenarios or shadow modes in which policy changes are evaluated without enforcing them to see potential impacts. The goal is to iterate – design, or update a policy, test it thoroughly, deploy and monitor it, and then repeat it whenever policies change or new threats emerge.

The importance of this approach is evident when we look at compliance failures caused by misconfigurations. Cloud security analysts often note that misconfigured access controls are a leading cause of data breaches – one study found misconfigurations contribute to nearly 70% of cloud security breaches.

A notorious example was the 2019 Capital One breach. The attacker exploited a misconfigured web application firewall in Capital One’s AWS cloud environment, which allowed access to a data storage that should have been protected. Over 100 million customer records were exposed. In the aftermath, Capital One not only faced customer backlash but also regulatory action – U.S. banking regulators fined the company $80 million for the lapse and required extensive improvements in cybersecurity oversight. Ultimately - a simple configuration mistake can escalate into a major compliance issue. With rigorous testing and code reviews of access configurations (in this case, cloud IAM and firewall settings), the misconfiguration might have been caught before deployment.

In the healthcare realm, one can imagine a hospital implementing a new role-based access policy for its EHR (Electronic Health Records) system. Suppose there’s a mistake and nurses in a certain department can suddenly see patients from another department, violating HIPAA’s minimum necessary rule. If untested, this could go live and result in unauthorized disclosures. If audited, the hospital could face penalties for each privacy violation. By contrast, an iterative testing framework would catch that regression – testers would simulate a nurse’s access and see the error, prompting a fix before any real patient data is wrongly accessed.

Beyond preventing breaches, testing frameworks help reduce operational risk. They give confidence that as you update authorization rules (perhaps to accommodate a new regulation or a business change), you’re not introducing new compliance issues. This is especially important for fintech startups scaling up: as they add features, they need to ensure permissions remain least-privilege. Any given code push could inadvertently bypass a check. With automated tests for authorization, these companies can catch issues in CI/CD pipelines. It’s analogous to running security unit tests – for example, a test asserting that “a user with role X should NOT be able to access resource Y” should fail if a developer’s change accidentally grants that access.

To implement this, some organizations treat authorization policies as code (policy-as-code) and use frameworks that allow writing tests for those policies. Over time, as policies evolve, the test suite grows, and compliance gets embedded into the development lifecycle. This also feeds into audit readiness: you can show auditors that not only do you have policies, but you continuously verify their correctness. Automated testing of access controls thus becomes a form of continuous compliance assurance. It is far better to catch and fix an access control mistake internally than to have an external audit or incident uncover it. The latter could mean regulatory fines or breach notifications; the former is just a normal part of your QA process. In summary, testing your authorization logic iteratively is as critical as testing your software. It ensures that policy misconfigurations – a common root cause of compliance failures – are found and fixed early. This proactive stance significantly reduces operational and compliance risk in any environment where authorization is complex and critical.

Choosing the right authorization system

Given the compliance stakes riding on authorization and access control, selecting the right authorization system is a strategic decision. The ideal solution should not only enforce fine-grained security policies but also make it easier to manage compliance requirements through its features. As you evaluate authorization systems for your organization, pay attention to the following key factors.

Granularity of control

Can the system enforce fine-grained, context-aware access rules? Modern compliance often demands enforcing least privilege at a very granular level – e.g., only allow doctors to see records of patients under their care, or only permit finance managers to approve expenses under a certain limit. A robust system should support Role-Based Access Control (RBAC) as well as Attribute-Based Access Control (ABAC) and policy-driven rules to cover nuanced scenarios. This granularity ensures you can implement complex compliance policies (like segregation of duties or need-to-know access) directly in the authorization layer.

Centralized policy management

In an enterprise, you might have dozens of applications each requiring authorization logic. A centralized authorization service or policy decision point means you define policies in one place and enforce them across your infrastructure and applications. This unification is critical for compliance – it ensures consistency across the board and makes audits easier (one source of truth for what your access rules are). Look for solutions that offer a central policy repository and management console, so security teams can update policies without having to alter code in every app.

Auditability and transparency

The system should maintain detailed audit logs of all authorization decisions. This means whenever a user attempts an action, the system can log whether it was allowed or denied and why (which rule applied). Such logs are incredibly useful in demonstrating compliance. If an auditor asks “why does user X have access to data Y,” you should be able to produce a clear policy and decision trail. Audit logs also help in forensic analysis if a violation is suspected – you can trace the sequence of access events.

Testability and CI/CD integration

As discussed, testing is crucial. The authorization system should allow you to test policies in isolation – perhaps through a “playground” or using a policy testing framework. This enables you to validate that new or modified rules work as intended before going live. Some advanced solutions provide a built-in policy testing suite or even a REPL for policies. Others integrate with CI pipelines so that policy changes can trigger automated tests.

Scalability and performance

From an operations standpoint, the system needs to scale with your user base and request load without becoming a bottleneck. In large organizations, every page load or API call might involve an authorization check. A good authorization service will be highly efficient (e.g., stateless and horizontally scalable) so it can handle thousands or millions of decisions per second. Scalability is indirectly a compliance concern too – if the auth system falters under load, it could fail-open (allowing access when it shouldn’t) or fail-closed (disrupting business operations). Either scenario is problematic.

Alignment with compliance standards

It’s worth evaluating whether the authorization solution has features or certifications that map to your compliance needs. Does it facilitate requirements for GDPR, HIPAA, SOC 2, etc.? Some products might offer templates or modules for certain regulations. Cerbos, being a policy-driven system, allows mapping your rules to specific compliance controls, and it’s built with security best practices that align to standards (for instance, it can be self-hosted for data privacy and is “private by design”, keeping sensitive authorization data within your environment).

Operational flexibility

Finally, consider how the system will integrate into your stack. Does it support the languages and environments you use (via SDKs or APIs)? Can it deploy on-premises or in your cloud for data control? Is it open-source (which can be beneficial for transparency and flexibility) or does it lock you to a vendor? These operational factors can affect compliance as well – e.g., some regulations might require that the authorization system runs in a certain environment for data residency.

In evaluating authorization solutions, buyers should seek a balance of security, compliance, and ease of use. A system like Cerbos exemplifies this balance.

• Cerbos, supports RBAC, ABAC, and even rule-based conditions (PBAC), allowing organizations to implement contextual, fine-grained permissions that align with regulations.
• It enables users to externalize authorization from application code and provides a central hub to manage and roll out policy change​. With a centralized authorization strategy, you reduce the risk of shadow policies or drift between systems.
• Cerbos includes audit logging as a core feature to record all authorization activities for accountability and compliance purposes​. Additionally, the system’s policies are human-readable and easily interpretable, so that compliance officers (who may not be developers) can review and understand them.
• The solution emphasizes “testable authorization” with built-in testing capabilities and even a CI/CD-friendly GitOps approach for deploying policy updates. This kind of environment encourages iterative improvements and helps catch compliance issues early, as discussed earlier.
• Cerbos is designed to be stateless and scalable, meaning it can run in distributed environments and grow without degradation in enforcing policies.
• Cerbos enables companies to more easily align with prevalent security standards like HIPAA, PCI DSS, and GDPR.
• Finally, Cerbos has an open-source core, and offers multiple deployment models (self-hosted, managed cloud, even an embedded WASM option), giving companies freedom to meet their specific compliance and infrastructure needs without vendor lock-in.

Organizations adopting Cerbos have reported smoother compliance audits and faster time-to-market. For example, the fintech firm Debite credited Cerbos with accelerating their compliance certification process and enabling them to ship products faster. By using an authorization platform, they could satisfy auditors about access controls without slowing down development.

In summary, choosing the right authorization system can significantly ease the burden of compliance. It provides the technical capabilities to enforce complex policies correctly and consistently, and it generates the evidence (logs, policy definitions, test results) that auditors and regulators require. When evaluating options, weigh the factors above and ask vendors how their product helps maintain compliance. The ideal solution will not only tighten security but also streamline the work of your compliance and ops teams – letting you achieve both security and agility.

Conclusion

Compliance needs to be a proactive strategy embedded into the DNA of your organization’s operations and systems. As we’ve discussed, the cost of neglecting compliance is simply too high, whether measured in fines, business losses, or damage to reputation. By contrast, companies that invest in strong compliance foundations (data governance, change control, audit logging, continuous testing, etc.) position themselves to avoid pitfalls and respond nimbly to evolving regulations.

Enterprise leaders must champion a culture where compliance and security are seen as enabling factors rather than obstacles. This means allocating resources to compliance initiatives, staying up-to-date with regulatory changes, and equipping teams with the right tools. Modern authorization solutions like Cerbos can be powerful allies in this journey – they translate your compliance policies into enforceable, verifiable action, and they reduce the manual overhead in managing those policies. With Cerbos or similar systems, organizations can simplify the complexity of access control, ensure consistent enforcement across applications, and generate the audit evidence needed to satisfy regulators. In short, these tools help bake compliance into your architecture, so that staying compliant becomes a natural outcome of how you run your business.

Ultimately, the mindset to adopt is that compliance is an ongoing commitment, not a one-time project. It’s about anticipating risks and addressing them before regulators or attackers do. By prioritizing compliance and leveraging robust authorization and security practices, organizations can not only be protected from penalties, but their overall operational efficiency and trust can be improved.

So, invest in compliance early, review it regularly, and choose partners and systems that reinforce your compliance goals. Staying compliant is challenging, but with the right approach and support, it is absolutely achievable – and it will pay dividends in the resilience and success of your organization.

If you’re interested in implementing externalized authorization to achieve and maintain compliance - try out Cerbos Hub or book a call with a Cerbos engineer to see how our solution can help streamline access control and secure your applications.