Mapping Security Frameworks and Regulations (ISO27001, NIS2, NIST etc.) to Cloud Architectures

On one side, there are engineering goals: scalability, simplicity, speed, cost. On the other, there is a landscape of regulations and frameworks that appear, at first glance, repetitive — ISO 27001, NIS2, GDPR, CRA, NIST, CIS, DORA etc.

Why do so may exist ?

The reason is simple: these frameworks are not trying to solve the same problem. Their principles and prescriptions overlap to an extent, but each one evaluates the architecture from a different angle.

At a high level , there are

• Security frameworks — A voluntary, structured set of best practices and guidelines. They provide a consistent language and structure for managing risk.
• Regulations — A mandatory requirement issued by a government or a governing body. If you fall under the scope of a regulation, you have no choice but to comply.

Here are a few

Short descriptions of these (for longer versions, scroll below)

Security Frameworks

• NIST CSF: A flexible guidebook that helps any business organize its security into five simple steps: Identify what you have, Protect it, Detect problems, Respond to attacks, and Recover quickly.
• ISO 27001: An well known standard that focuses on having a solid management process to identify risks and keep information safe, accurate, and available.
• CIS Critical Security Controls: A prioritized "to-do list" of the most important technical actions that stop the majority of common cyberattacks.
• SOC 2: A set of criteria used primarily by service companies to prove to their customers that they handle data securely and keep their systems running reliably.
• CSA Cloud Controls Matrix (CCM): A specialized checklist designed specifically for the cloud that explains how traditional security rules should be applied in environments like AWS.

Regulations

• GDPR: A strict European law that gives people control over their personal data and punishes companies that don't protect it or use it fairly.
• NIS 2 Directive: A European rule that forces "critical" industries — like energy, water, and banks — to meet high security standards and report major hacks within 24 hours.
• HIPAA: A U.S. law that mandates anyone handling medical information must keep patient data private and secure from unauthorized eyes.
• PCI-DSS: A mandatory set of security rules for any business that handles credit card information to prevent fraud and data theft.
• DORA: A European law specifically for the financial sector to ensure banks can stay online and recover quickly from digital glitches or cyberattacks.

Overlaps of areas addressed by these

Architecturally, all of these direct systems in the same direction. For example

Clear asset ownership

• Explicitly mentioned system and data owners, not shared or implicit responsibility
• Asset inventories that include services, data stores, identities, and dependencies
• Classification of assets by criticality and sensitivity, not just by type

Strong identity and access control

• Least-privilege roles defined by function
• Separation between human, service, and automation identities
• Temporary and auditable privileged access instead of permanent admin roles

Logging, monitoring, and visibility

• Centralized, tamper-resistant logging across all critical components
• Logs that answer who did what, when, and why, not just that something happened
• Correlation across identity, application, and infrastructure events
• Monitoring that drives alerts, escalation, and response instead of passive dashboards

Design for resilience

• Isolation between components
• Automated recovery paths that are tested under realistic failure scenarios
• Well defined recovery objectives aligned to business criticality
• Designs that limit blast radius during outages

Secure defaults

• Secure configurations enabled by default
• Guardrails that prevent unsafe deployment
• Infrastructure as code to reduce configuration drift and manual fixes

Now I will go a bit deeper and mention the highlights of these individually, and cover the architectural angle they cover.

ISO 27001 + Annex A Controls

ISO 27001 is probably the most recognized security standard worldwide. If you work with international clients or partners, you'll run into this one.

The standard has two main parts. The core standard explains how to build and maintain your security program. Annex A lists 93 (at the time of writing) specific security controls. Organizations can obtain official certification by undergoing audits.

It forces you to think systematically about security and it forces clarity.

Annex A has controls in four categories

• Organizational — Rules for things like "Cloud Services" or "Supplier Relationships."
• People — Background checks and security training for the team.
• Physical — Locks on doors and sensors in the server room.
• Technological — Topics like encryption, Identity Management (IAM), and Web Filtering etc. These controls are the ones we Architects most work with.

Cloud implementation: All major cloud providers (AWS, Azure, GCP) are ISO 27001 certified for their infrastructure. But that doesn't mean the applications running on their infrastructure are certified. Refer to the shared responsibility model. You need to implement controls for your systems. Examples

• Use identity and access management properly.
• Enable encryption.
• Set up logging.
• Configure backup policies. etc etc.

The cloud provider gives the tools. The tools need to be used correctly.

SOC2

SOC 2 is an audit framework focused on how service providers handle customer data. Unlike ISO 27001, which you can certify against, SOC 2 is about generating audit reports. There are two types. Type I shows your controls exist at a point in time. Type II shows they've been working effectively over several months.

It makes you think about reliability and trust. It's not enough for your system to be secure. It also needs to be available, accurate, and predictable (also over a period of time).

https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2

SOC 2 is built around five "trust service criteria":

• Security (required for everyone)
• Availability (is your system up when needed?)
• Processing integrity (does your system do what it's supposed to do?)
• Confidentiality (is sensitive data protected?)
• Privacy (are you handling personal information correctly?)

NIST Cybersecurity Framework (CSF)

NIST is the National Institute of Standards and Technology, an American government agency. This framework is used, especially by organizations working with US federal agencies. It's less prescriptive than ISO 27001. Instead of telling you exactly what controls to implement, it gives you a framework for understanding and managing cybersecurity risk. This is not a certification program.

https://www.nist.gov/cyberframework

The NIST CSF is built around five core functions: Identify, Protect, Detect, Respond, and Recover.

• Identify means understanding what you're protecting (Asset inventory, Data classification etc)
• Protect means implementing safeguards (Access controls, Encryption etc.)
• Detect means finding security events when they happen (logs, monitoring etc.)
• Respond means reacting to incidents effectively (Incident response, Communication etc.)
• Recover means getting back to normal operations (Backup and restore, disaster recovery etc.)

Cloud implementation: Same as earlier. The framework gives you a mental model. The cloud gives you the tools and these need to be used.

CIS Controls

The Center for Internet Security publishes the CIS Controls. These are specific, actionable security measures ranked by priority.

Cloud implementation: Many cloud security tools map to CIS Controls. Examples:

• Use configuration management to enforce secure settings.
• Implement MFA everywhere.
• Enable encryption by default.
• Set up centralized logging.
• Scan for vulnerabilities regularly.

The controls tell you what, the cloud tells you how.

Cloud Security Alliance (CSA) Cloud Controls Matrix

CSA is an industry organization focused specifically on cloud security. Their Cloud Controls Matrix is designed for cloud environments.

The CCM is a set of 197 control objectives organized into 17 domains. It maps to other frameworks like ISO 27001 and NIST, but it's built specifically for cloud computing.

The CCM addresses cloud-specific concerns that general frameworks sometimes miss. Things like multi-tenancy, virtualization security, and shared responsibility models.

Some key topics that impact architecture could be

• Application and interface security (APIs, web apps)
• Audit and assurance (logging in cloud environments)
• Data security and encryption
• Identity and access management
• Infrastructure and virtualization security
• Interoperability and portability (avoiding vendor lock-in)
• Security incident management in cloud contexts

GDPR

The General Data Protection Regulation is European law, but it affects anyone processing data about EU residents. It gives individuals rights over their personal data. It requires organizations to protect that data and use it responsibly.

You can't just collect everything and figure out what to do with it later. You need purpose, justification, and controls around the data.

GDPR forces architectural decisions around:

• Collect only what you need
• Use data only for stated purposes
• Delete data when no longer needed
• Data portability (users can take their data elsewhere)
• Right to erasure (users can request deletion)
• Detect and report breaches quickly
• Privacy by design (build privacy into systems from the start)
• Where it is stored

https://gdpr.eu/what-is-gdpr/

Cloud implementation: Examples

• Use data classification and tagging to mark personal data.
• Implement strong encryption.
• Set up data retention policies that automatically delete old data.
• Use regional cloud deployments to control where data is stored.
• Build APIs that can extract or delete user data.
• Enable comprehensive logging to prove compliance.

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA is the US law protecting medical information.

HIPAA requires specific technical safeguards. These are divided into required controls and addressable controls (you must either implement them or document why they don't apply).

Key architectural requirements:

• Access controls limiting who can see health information
• Audit controls tracking who accessed what
• Integrity controls ensuring data isn't improperly altered
• Transmission security protecting data in transit
• Encryption for data at rest and in transit

Payment Card Industry Data Security Standard (PCI DSS)

It's technically not a law, but it's enforced by payment card brands. If you accept credit cards, you must comply.

https://www.pcisecuritystandards.org/standards/pci-dss/

Core architectural requirements are

• Network segmentation isolating cardholder data
• Strong access controls with unique IDs for everyone
• Encryption of cardholder data in transit and at rest
• Vulnerability management and patching
• Regular security testing
• Comprehensive logging and monitoring

Cloud implementation: Major cloud providers have PCI DSS certified services. But like other compliance requirements, you're responsible for your implementation.

Network and Information Security Directive 2 (NIS2)

The Network and Information Security Directive 2 is European legislation focused on critical infrastructure and essential services.

It applies to organizations providing essential services (energy, transport, health, digital infrastructure) and important services (postal services, food production, manufacturing). It requires these organizations to manage security risks and report incidents.

NIS2 is less interested in controls and more interested in outcomes.

• Can the organization withstand incidents?
• Can it detect them quickly?
• Can it recover in a predictable way?

https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

Key architectural concerns:

• Risk management processes
• Business continuity planning
• Supply chain security
• Incident handling procedures
• Crisis management
• Security testing and audits

Cloud implementation: Examples:

• Design for high availability across multiple availability zones.
• Implement disaster recovery with regular testing.
• Monitor third-party dependencies.
• Set up incident detection and alerting.
• Create runbooks for common scenarios.
• Use redundancy and failover capabilities.
• Document everything.

Digital Operational Resilience Act (DORA)

DORA requires financial entities to manage information and communication technology (ICT) risk and ensure operational resilience — DORA applies to banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and their critical third-party ICT service providers.

It focuses heavily on testing, third-party risk, and incident management. Unlike general security frameworks, DORA assumes you will have incidents. The question isn't "if" but "when" and how well can you handle it.

Architecturally this means implementing robust incident management, testing resilience through scenarios, managing third-party ICT dependencies, and maintaining detailed ICT risk registers.

Cloud implementation: Examples:

• Deploy critical systems across multiple availability zones/regions at minimum.
• Implement monitoring and alerting across all layers — infrastructure, platform, application, and business metrics.
• Build disaster recovery automation using infrastructure as code.
• Use managed services where possible. Avoid deep vendor lock-in.
• Document all third-party cloud services and dependencies.
• Maintain detailed runbooks for incident response
• Test backup and recovery
• Design network architectures with redundancy
• Replicate critical data across regions. Use database services with automatic failover. Implement data validation to detect corruption.

Building a compliance architecture: Practical steps

Here is a rather generic practical approach to building cloud architecture that addresses these frameworks and regulations.

Step 1: Know what applies your business

Not every framework and regulation applies to every business. Figure out which ones matter for you. Are you handling EU citizen data? You need GDPR. Are you processing payments? You need PCI DSS. Are you selling the fact how well your controls work ? SOC 2 helps.

Step 2: Choose a foundational framework

Pick one comprehensive framework as your foundation. ISO 27001 and NIST CSF are excellent choices. These give you a complete security program. Everything else builds on this foundation.

Step 3: Design with security principles

Regardless of specific requirements, certain principles apply everywhere.

• Defense in depth — Layer your security controls. If one fails, others protect you.
• Least privilege — Give people and systems only the access they need, nothing more.
• Encryption everywhere — Protect data at rest and in transit.
• Logging and monitoring — You can't protect what you can't see. Log everything relevant.
• Separation of duties — Divide critical tasks so no single person controls everything.
• Regular updates — Keep systems patched and current.

Step 4: Use Cloud-Native security services

• Every major cloud provider offers security services. Use them. They're often easier and more secure than building your own.
• Identity and access management: Use the cloud provider's IAM system properly.
• Encryption services: Use managed encryption key services.
• Logging and monitoring: Use cloud-native logging and monitoring tools.
• Network security: Use virtual networks, security groups, and firewalls.
• Compliance tools: Use built-in compliance checking and reporting.

Step 5: Document everything

• Compliance requires evidence — Document your architecture decisions, security controls, procedures.

Step 6: Automate compliance checking

Manual compliance checking doesn't scale. Use automation to continuously verify your controls are working. Cloud providers offer compliance tools. Use them. Set up alerts when configurations drift from approved settings. There are many 3rd party tools (Non cloud provider) available to do this too.

Step 7: Test your controls

Don't assume your security controls work. Test them. Run disaster recovery drills. Conduct security assessments. Try to break your own systems in test environments and fix what you find.

Step 8: Keep learning

Regulations change. Threats evolve. New frameworks emerge. Stay current. Follow security news. Attend conferences. Learn from incidents (yours and others').