Regulatory Compliance: Essential Guide for 2026

Orca Security Team · 10-minute read

Key Takeaways

• Regulatory requirements carry legal authority, while industry standards may become binding through contracts, customer requirements, or other compliance programs. The source of the obligation affects both enforcement and evidence.
• SOC 2 and PCI DSS sit on the contractual side of that line. The AICPA calls SOC a service that CPAs provide, and the PCI Security Standards Council points entities to the payment brands’ own compliance programs.
• Industry decides the obligation set more than company size does. Healthcare, life sciences, financial services, and EU critical sectors are each named by a different instrument.
• One internal control set mapped to many obligations is the arrangement that survives regulatory change, because a new rule then lands on controls that already exist.
• Many of the artifacts these rules demand are technical facts about a cloud estate, and Orca collects them continuously without deploying agents.

Regulatory compliance is the state of meeting rules that a government body writes and enforces. A statute or a regulation is enforced by a government body with legal authority. Frameworks and standards may become binding through contracts, customer requirements, certification programs, or other industry mechanisms. That difference decides both the consequence and the evidence.

Most pages on this subject list HIPAA, GDPR, SOX, PCI DSS, and SOC 2 in a single set. Two of those five are not government rules at all. Sorting them correctly changes who can penalize the organization and what has to be produced when someone asks for proof.

This guide defines the term, separates the three kinds of obligation, and maps the main industries to the instruments that bind them. It then covers how a program is built and staffed, what software supports it, where programs fail, and how to measure the result.

What is Regulatory Compliance?

Regulatory compliance is the state of meeting obligations created by law and enforced by a government agency. Asking what is regulatory compliance in the abstract gets that short answer. Asking it about one organization takes longer, because the obligation set depends on the sector, the jurisdiction, and what the organization does with data.

Three different things get filed under the same heading. A regulation carries the force of law. A standard carries the weight of a contract. An internal policy is created by the organization itself and establishes requirements for the people, systems, and processes within its scope.

The same split shows up in how cloud compliance is usually defined. That definition separates regulatory requirements from industry standards and internal security policies.

Who Enforces Each Kind of Obligation

A regulation names its enforcer. A legislature passes a statute, an agency writes the rule that implements it, and that agency brings the action when the rule is broken. The reader can look up a section number and read the operative sentence.

A standard has no enforcer of that kind. The American Institute of Certified Public Accountants describes System and Organization Controls as “a suite of service offerings CPAs may provide” in connection with an organization’s controls. A SOC 2 report is an accountant’s examination against the Trust Services Criteria. No agency issues it, and no agency can penalize an organization for what it says.

PCI DSS occupies a third position. The PCI Security Standards Council publishes the standard, then points elsewhere for the obligation. Its own guidance says each participating payment brand member has “their own PCI compliance programs” and that entities “should contact the payment brands directly for information about their compliance programs and reporting requirements.” The duty arrives through a merchant agreement, in the same way as most of the standards most cloud programs are held to.

The distinction is not academic. It decides who can compel an answer, which deadline applies, and what form the proof takes.

A regulator reads a section number and asks for the record that section names. A customer reads a report and asks for the auditor’s opinion. Treating all five of the commonly listed obligations as one category means preparing the wrong evidence for at least two of them.

Why Regulatory Compliance Matters for Organizations

The enforcer decides the consequence, and the consequences are not interchangeable. A missed statutory duty produces a government action against a written deadline. The Securities and Exchange Commission requires a material cybersecurity incident to be reported on Item 1.05 of Form 8-K. That filing is generally due within four business days of the materiality determination, contained incident or not.

A missed contractual duty produces a commercial consequence instead. A payment brand sets the validation and reporting requirements a merchant has to meet, and an acquiring bank can end the relationship. A buyer who wanted a SOC 2 report can shop elsewhere. No regulator appears in any of those outcomes, and none is smaller for it.

Contractual duties also move faster, since a counterparty can change terms without a rulemaking process. Compliance therefore runs on two tracks at once. The statutory track sets a floor the business cannot trade against, and failing it turns a security problem into a legal one. The commercial track decides which customers can be sold to and on what terms.

One control usually ends up described twice. An agency hears it in the words of a rule, and a customer hears it in the words of an auditor.

Regulatory Compliance Across Key Industries

Industry is a major factor in determining an organization’s regulatory obligations, alongside jurisdiction, activities, data handled, and organizational characteristics such as size. A twenty-person clinic and a national hospital chain answer to the same rule, written in the same section. The rule lets each one weigh its own size, complexity, and capabilities when choosing measures, but the standard itself does not change. The table below maps each sector covered here to the instrument that binds it and the outcome that instrument demands.

Sector	Instrument	What it demands
Healthcare	HIPAA Security Rule, 45 CFR 164.312	Access control, audit controls, integrity, authentication, and transmission security for electronic protected health information
Life sciences	FDA electronic records rule, 21 CFR Part 11	Secure, time-stamped audit trails covering entries and actions that create, modify, or delete electronic records
Payments	PCI DSS, assessed under each payment brand’s program	Assessment and reporting on the terms set by the brand and the acquiring bank
Listed companies	SEC Regulation S-K Items 106 and 308	An annual description of cybersecurity risk processes, and management’s report on internal control over financial reporting
Any sector, EU personal data	GDPR Article 32	Security measures appropriate to the risk, plus a process for regularly testing their effectiveness
Critical sectors, EU	NIS2 Directive, Article 21	All-hazards risk-management measures for entities of a type listed in Annex I or Annex II

Healthcare and Life Sciences

Healthcare regulatory compliance in the United States starts with the Security Rule under HIPAA, codified at 45 CFR 164.312. Its audit controls standard is written as a direct instruction. “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” Evidence can include retained audit logs and records demonstrating that relevant system activity is reviewed in accordance with the organization’s procedures.

Several specifications in the same section are marked addressable rather than required, including encryption and automatic logoff. Addressable does not mean optional.

Section 164.306(d)(3) requires the entity to assess whether the specification is a reasonable and appropriate safeguard in its environment. If it is, the entity implements it. If it is not, it documents why and implements an equivalent alternative measure where that is reasonable.

That written reasoning is itself an artifact an assessor can ask for. Most of the underlying work now happens in cloud environments. That is why meeting HIPAA requirements in the cloud has become the practical form of the question.

Pharmaceutical regulatory compliance runs on a different instrument. The Food and Drug Administration’s electronic records rule sits at 21 CFR Part 11. It covers records kept in electronic form under FDA’s own records requirements, plus records submitted to the agency. It does not reach every file a company stores electronically.

Within that scope, section 11.10(e) requires “secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records.”

A second sentence in the same paragraph rules out overwriting. “Record changes shall not obscure previously recorded information.” The artifact is an append-only trail, not a current-state export.

Financial Services

Card data brings a duty that arrives by contract. PCI DSS compliance is assessed under a program run by the payment brand. The shape of that assessment follows how the merchant handles account data. The PCI Security Standards Council adds that local laws and regulations can affect how its standards apply.

The enforcement path leaves the technical work of securing payment data unchanged. It does change who sets the deadline.

Public companies carry a statutory duty over financial reporting. Item 308 of Regulation S-K requires management’s annual report on internal control over financial reporting, and it is strict about the conclusion. “Management is not permitted to conclude that the registrant’s internal control over financial reporting is effective if there are one or more material weaknesses in the registrant’s internal control over financial reporting.”

Change-management records for systems supporting financial reporting can form part of the evidence used to demonstrate effective internal controls. An uncontrolled change to a reporting system is how a weakness gets in.

The same filer carries a second, newer duty over cybersecurity. Item 106 of Regulation S-K opens with a direct instruction. “Describe the registrant’s processes, if any, for assessing, identifying, and managing material risks from cybersecurity threats in sufficient detail for a reasonable investor to understand those processes.” It also asks whether those processes are integrated into overall risk management.

The artifact here is a written description of a process that a reader outside the company can follow. A passing control test does not satisfy it. EU financial entities carry a further sector instrument in the Digital Operational Resilience Act.

Cross-Sector Data Protection

The General Data Protection Regulation applies by activity rather than by sector. Article 32 requires controllers and processors to “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk,” then lists what those can include. It names encryption, resilience, and restoration after an incident, then adds “a process for regularly testing, assessing and evaluating the effectiveness” of those measures. That last item turns test results into evidence, and applying it to GDPR in the cloud is where the artifact usually sits.

Sector scope can also arrive through a directive. NIS2 applies to entities of a type listed in its Annex I or Annex II that “qualify as medium-sized enterprises” or exceed those ceilings. Annex I covers energy, transport, banking, health, digital infrastructure, public administration, and space, among others.

United States cloud providers meet a different gate. Under FedRAMP’s 2026 consolidated rules, agencies must promote cloud services that are FedRAMP Certified when the use falls within the program’s scope. That scope carries published exclusions, and only a federal agency decides whether a use case sits inside it. A FedRAMP authorization gates cloud services, not every supplier.

Building an Effective Regulatory Compliance Program

A program that tracks obligations one at a time falls behind the first time two rules overlap. The arrangement that holds up maps many obligations onto one internal control set. A new rule then lands on controls that already exist, and adopting it becomes a mapping exercise instead of a project with its own budget.

Obligation Register and Control Mapping

The register is a list with one row per obligation. GDPR Article 30 already requires a controller to “maintain a record of processing activities under its responsibility,” so the habit has a statutory precedent. Article 30(5) provides a limited exemption for organizations employing fewer than 250 people, but that exemption does not apply in several circumstances, including where processing is not occasional, is likely to result in risk to individuals, or involves certain special-category or criminal-conviction data.

Extending the record to every rule the organization answers to costs little and pre-answers most of what an assessor asks.

Each row carries the same fields:

• The instrument and the exact section, so the operative text can be read instead of paraphrased.
• The enforcer, since that determines both the consequence and the deadline.
• The outcome the section demands, stated in the section’s own words.
• The internal control that produces that outcome, drawn from the control set obligations map onto.
• The artifact that proves the control ran, and the system where that artifact is stored.

Two obligations that demand the same outcome share a control and an artifact, and recording that overlap is the whole point of the mapping. HIPAA’s audit controls standard asks for mechanisms that record and examine activity in systems holding health data. GDPR Article 32 asks for measures appropriate to the risk, tested for effectiveness. A SOC 2 Type 2 examination asks for evidence that logging and review operated across the reporting period.

A well-designed logging and review control may contribute evidence across all three, provided its scope, operation, retention, and review frequency satisfy the requirements mapped to it. Without the mapping, the same team builds that control three times under three project names, then produces three sets of evidence that do not reconcile. The register also shows which controls carry the most obligations, and those are the ones that deserve the deepest testing.

Ownership, Training, and Attestation

Every row needs clear accountability, with an identified owner or responsible role that can be traced to the people performing and reviewing the control. “Security owns it” produces nothing when an assessor asks who reviewed the access logs last quarter. Person-level ownership works alongside the governance structure that assigns ownership at the committee level, and it is the layer that answers specific questions.

Training and attestation are the two records that show ownership was accepted. A completed training record shows the owner knew the duty. A signed attestation shows the owner confirmed the control ran during the period. Obligations passed to a supplier need the same treatment, written into the contract instead of assumed from a certificate.

Regulatory Compliance Software and Technology Solutions

Regulatory compliance software covers a narrow set of jobs, and buyers get into trouble by expecting one product to do all of them. The categories below describe what tools in this space actually do with the register. Managing compliance across multiple cloud providers is a separate problem, handled by security tooling and not by the systems here.

• Regulatory change monitoring watches official sources for amendments, then flags which register rows a change touches.
• Obligation libraries ship pre-written obligation text for common instruments, so the register does not start from an empty sheet.
• Control mapping links one internal control to the several obligations it satisfies, and exposes the obligations no control covers.
• Policy management holds the current version of each internal policy, its approver, and its review date.
• Attestation tracking records who signed what and when the next signature falls due.

The register is the asset underneath all five. A product that will not export it leaves the organization dependent on a vendor for its own compliance record. That is a weak position when the contract comes up for renewal.

Two capabilities separate the useful products from the rest. The obligation text has to be editable, so it matches how the organization reads the section. One control has to attach to many obligations without being duplicated. A tool missing either capability tends to end with the register maintained in a spreadsheet alongside it.

Common Challenges in Compliance Management

Three failures are worth naming, and none of them depends on program size. The register drifts away from what the organization actually does, because nobody owns updating it when a system changes. The control set gets rebuilt per obligation, so the same access review runs four times under four names. Ownership sits with a department, so it sits nowhere the moment a specific question arrives.

Cloud deployments add a fourth failure. Part of the evidence belongs to the provider and part belongs to the customer, split according to the shared responsibility model. A team that treats the provider’s certification as covering its own configuration finds the gap during an assessment. The provider attests to the infrastructure it operates, and the customer still answers for what it built on top of that infrastructure.

All four are record-keeping failures. Each one is a record nobody was assigned to keep current, so more training does not touch them. The fix is the same in every case. Attach the record to a person, attach the person to a trigger, and fire the trigger on system change instead of on a date.

Best Practices for Regulatory Compliance Risk Management

Regulatory compliance risk management ranks obligations by what happens when they fail. Prioritization should consider legal or contractual consequences, deadlines, likelihood of failure, business impact, and the organization’s exposure if the obligation is missed.. The ranking should also weigh how visible a failure would be, because a control that fails quietly costs more than one that fails loudly.

The practices that hold up borrow their shape from cloud risk management and apply it to obligations instead of assets:

• Rank every obligation by enforcer, deadline, and how quickly a failure would surface.
• Test the control carrying the most obligations first, since one failure there spreads across rows.
• Record the reasoning behind each addressable or discretionary decision at the moment it is made.
• Re-run the mapping when a system changes, not only when a rule changes.
• Give every accepted gap a named owner and an expiry date, so it cannot become permanent by default.

The last practice is the easiest one to skip. An accepted gap with no expiry date becomes a permanent exception by default, and it is still an exception when an assessor reads the register. Recording the acceptance is cheap while the decision is fresh and expensive to reconstruct two years later.

Measuring Compliance Effectiveness and Reporting

A regulatory compliance audit and continuous monitoring answer different questions. The audit asks whether a control operated across a stated period, and it reaches that judgment after the window has closed. Monitoring asks whether the control is operating now. Audit logs feed both, and reporting across multiple providers has to pull from every provider that holds them.

Measures that track the register beat measures that track the calendar:

• The share of obligations with a named owner and a current artifact.
• The number of obligations mapped to each control, which shows where concentration risk sits.
• The age of the oldest artifact nobody has reviewed.
• The lag between a system change and the register update that should follow it.

Reporting then has two audiences. A board wants the concentration figure and the trend on unreviewed artifacts, because both describe exposure. An assessor wants the artifact itself, for a named control, across a named period. A report built only for the board leaves the second request to be answered by hand, and that is where audit weeks disappear.

How Orca Evidences the Technical Controls Regulators Ask About

Orca is a cloud security platform. It does not hold the policy library, run the attestation campaigns, or keep the training records a compliance function owns. Deciding which instruments bind an organization also stays a legal judgment. What Orca covers is the technical half of the evidence, measured against the controls a framework asks for.

Many of the artifacts in the table above are technical facts about running infrastructure. An access log, an encryption setting, a network path, and a retention configuration are all properties of live systems. Orca’s SideScanning™ technology reads them from the workloads’ runtime block storage without requiring agents. The picture therefore stays current between assessments.

The platform checks cloud configurations and policies against more than 150 industry and regulatory frameworks, including CIS control benchmarks. Teams can configure custom frameworks where an obligation has no off-the-shelf mapping. Evidence gathered in the week before an assessment describes that week, while evidence gathered continuously describes the period the assessor asked about. To see multi-cloud compliance reporting built on cloud security posture management and agentless collection, Get a Demo.

Frequently Asked Questions About Regulatory Compliance

Who is accountable when an obligation is missed?

The named owner in the register answers first, and the executive who accepted the risk answers next. The question that matters is who held the authority to act. A register row assigned to a department is therefore weaker than one assigned to a person. Where a supplier performs part of the work, accountability depends on the applicable regulation, contractual terms, and allocation of responsibilities between the parties.

How often should an obligation register be reviewed?

A fixed calendar misses the changes that matter most. Two triggers are worth wiring in: a change to an instrument, and a change to a system in scope. A quarterly sweep catches what both triggers miss, and it stays short when the triggers are working. An annual-only review leaves far more time for rows to drift between checks.

What happens when two obligations conflict?

Many apparent conflicts turn out to be two different retention periods for the same record. Where requirements genuinely conflict, legal or compliance teams should determine which obligation governs and document the resolution rather than assuming that the stricter requirement automatically controls. A data residency rule that collides with a disclosure duty needs legal advice rather than an engineering decision. Record the resolution in the register row, because the next assessor will ask about it.

Does a cloud provider’s certification cover its customers?

Not by itself. The provider certifies the infrastructure it operates, and the customer still answers for the configuration built on top. A provider attestation is one input to a customer’s evidence set instead of a replacement for it. Reading the scope section of the provider’s report shows where the boundary actually falls, and that section is the part worth reading closely.

How long does compliance evidence have to be kept?

The instrument that demanded the evidence sets the period. FDA’s electronic records rule is explicit that audit trail documentation “shall be retained for a period at least as long as that required for the subject electronic records” and has to be available for agency review. Other instruments say less, and the working rule is to keep evidence at least as long as the enforcer can bring an action. Deleting on a generic schedule is how organizations lose the proof that a control ever ran.