Governance & compliance
Cybersecurity compliance starts with scope, not a logo.
GDPR, NIS2, HIPAA and DORA create different obligations. The right starting point is to identify the jurisdictions, information, sectors and contracts that apply to the business.
Laws, regulations and standards are not interchangeable
GDPR is an EU regulation focused on personal data. Its security requirements call for measures appropriate to risk, while its breach-notification rules can require a controller to notify the competent supervisory authority within 72 hours after becoming aware of a personal data breach, where feasible, unless the breach is unlikely to create a risk to people's rights and freedoms. A security incident is not automatically a reportable personal data breach, so the facts and roles still matter.
NIS2 is an EU directive aimed at a high common level of cybersecurity across specified critical and important sectors. It is implemented through national law, which means an organization must check the rules in the relevant Member State. NIS2 addresses risk-management measures, management accountability, supply-chain security and phased incident reporting. The European Commission describes an early warning within 24 hours and an incident notification within 72 hours for significant incidents, followed by later reporting requirements.
Standards and contractual programs play a different role. ISO/IEC 27001 provides a framework for an information security management system, while PCI DSS is a payment-card industry standard. They may be required by a customer, contract or certification objective, but they should not be presented as statutes. A certification also does not prove compliance with every law that may apply.
Sector and information determine the obligation
HIPAA is a United States federal law and regulatory framework for specific health-sector relationships. The HIPAA Security Rule protects electronic protected health information handled by covered entities and their business associates. It requires reasonable and appropriate administrative, physical and technical safeguards. HIPAA does not apply to every company that happens to hold health-related information, so status as a covered entity or business associate must be established rather than assumed.
DORA is an EU regulation for digital operational resilience in the financial sector. It brings ICT risk management, incident reporting, resilience testing and third-party risk into a sector-specific framework. A technology provider may also face contractual and oversight consequences when serving a regulated financial entity, even when the provider is not regulated in exactly the same way as its customer.
Other rules can apply at the same time. State privacy laws, national cybersecurity laws, contractual notification clauses and professional obligations may overlap. The safest compliance statement is therefore specific: name the entity, service, data, location and role being assessed. Avoid saying that a product or vendor is simply 'GDPR compliant' or 'HIPAA certified' without defining the boundary and supporting evidence.
Build one control system with several legal views
Create an applicability register that connects each obligation to the business activities in scope, the accountable owner and the evidence required. Then map common controls such as access management, risk assessment, logging, supplier review, incident response, backup and recovery to those obligations. One well-operated control can support several requirements, but the reporting thresholds, legal roles and evidence expectations may still differ.
Maintain a separate incident-notification matrix. It should identify who evaluates a suspected event, which facts must be preserved, who obtains legal advice and which deadlines may apply. The clock can start before an investigation is complete, so notification decisions should not depend on one unavailable executive or an improvised spreadsheet.
Finally, treat compliance as an operating cycle. Review scope after new markets, acquisitions, products, data uses and suppliers. Test controls, retain evidence and record exceptions with approval and review dates. This guide provides a practical orientation, not legal advice; qualified counsel should confirm the rules and interpretations for the organization.
In practice
One provider, two customers, different obligations
Illustrative scenario, not a client case study.
Imagine a Tampa-based managed technology provider serving a dental practice in Florida and an EU company that collects customer information. The provider should not place both customers under one generic 'cyber compliant' checklist.
- For the dental practice, the parties first confirm whether the practice is a HIPAA covered entity and whether the provider creates, receives, maintains or transmits ePHI as a business associate. If so, they define the business associate agreement, safeguards, incident process and evidence that apply to that relationship.
- For the EU customer, the parties identify controller and processor roles, locations, personal-data processing and contractual instructions. They assess GDPR requirements and separately determine whether the customer's sector and national implementation place it within NIS2 scope.
- The provider operates shared controls for identity, logging, recovery and supplier review, but keeps separate legal-role records and notification paths. Counsel validates uncertain scope and the contracts reflect the actual services rather than marketing language.
A common security program can support both customers, but the legal basis, protected information, contractual role and notification route remain distinct.
What to put in place
- Map the entity, service, jurisdictions, information types and regulated roles.
- Separate legal requirements from certifications and contractual standards.
- Connect each obligation to an owner, control, evidence and review date.
- Maintain a legally reviewed incident-notification matrix with applicable deadlines.
The takeaway
Do not begin with a badge that says compliant. Begin with scope, translate each applicable obligation into operated controls, and keep evidence that shows how those controls work in the defined environment.