Cloud security and governance for AWS and Azure, built in from the design stage

What is at stake: cloud security is decided in the configuration

In the cloud, most security risk lies in what you configure, not in the physical infrastructure, which the provider secures. What remains your responsibility is everything you set up: identities and permissions, network exposure, encryption, logging, backups. This is the shared responsibility model, and it is where most risks sit: an access key forgotten in a repository, a storage bucket made public for a test, an administrator role granted “temporarily” two years ago.

The difficulty grows with scale. One AWS account or Azure subscription can be managed by hand; ten or fifty, with several teams, cannot be managed without automated rules. Cloud governance means setting those rules once, centrally, so that every new environment is compliant from the start.

What we put in place

Identity and access management (IAM)

• Centralised authentication through your directory (AWS IAM Identity Center, Microsoft Entra ID), mandatory MFA, removal of permanent users and access keys.
• Roles by job function and environment, on least privilege, with traced break-glass access.
• Workload identities (roles for applications and CI/CD pipelines) rather than stored secrets.
• Periodic, tool-supported access reviews.

Central guardrails

• A structure for AWS accounts (AWS Organizations, organisational units) or Azure subscriptions (management groups) that separates production, non-production, security and logging.
• Service Control Policies on AWS and Azure Policy on Azure: allowed regions, a ban on disabling logging, mandatory encryption, blocking public access to storage, required tags.
• These foundations belong to the landing zone, which we build with you as part of an AWS or Azure project.

Data protection

• Encryption at rest and in transit by default, managed keys (AWS KMS, Azure Key Vault) with a rotation policy and separation of duties.
• Secrets kept in a dedicated vault, never in code or in plain-text pipeline variables.
• Backups isolated from the production account and tested by restoring them.

Logging and detection

• API logs (AWS CloudTrail, Azure activity log) centralised in a dedicated account or workspace, write-protected and retained according to your obligations.
• Native detection services (Amazon GuardDuty, AWS Security Hub, Microsoft Defender for Cloud) enabled and connected to a handling process: who receives the alert, who decides, and within what time.
• Continuous configuration checks rather than an annual audit.

Security in the delivery pipeline

Rules are written as code and versioned with the infrastructure. Infrastructure plans are analysed before they are applied (detecting public resources, missing encryption, overly broad permissions). This is the natural extension of our work on Terraform and Infrastructure as Code.

Compliance: HDS, GDPR, NIS2

Compliance cannot be bolted on afterwards; it follows from an architecture that produces the expected evidence (audit trails, encryption, access control, reversibility).

• HDS (Hébergement de Données de Santé, the French certification for hosting health data): Feekr’s founder has designed and operated AWS infrastructure as code in this regulated context. We know where the host’s certification ends and what remains your responsibility.
• GDPR: data location, access minimisation, logging, retention periods.
• NIS2: Directive (EU) 2022/2555 extends cybersecurity obligations to many more entities. How it applies in France depends on the national transposition law and its implementing texts: as of publication (October 2026), check your status and obligations with ANSSI, the French national cybersecurity agency. Text of the directive: EUR-Lex, Directive (EU) 2022/2555. We help you translate the technical measures into cloud configuration; we do not replace legal advice.
• Reversibility: open formats, infrastructure described as code, documented exit procedures, so you are not dependent on a provider without a plan B.

Concrete deliverables

• Assessment of the security and governance of your accounts or subscriptions, with risks ranked by severity and remediation effort.
• Organisation model for accounts or subscriptions and roles.
• Guardrail catalogue (SCPs, Azure Policy) as code, tested and documented.
• Centralised logging and detection foundation, with an alert handling process.
• Compliance matrix linking your requirements (HDS, GDPR, NIS2, internal policy) to the technical controls in place.
• Runbooks: handling break-glass access, responding to an alert, reviewing access.

Pitfalls to avoid

Pitfall	Consequence	What we do instead
Guardrails that are too strict on day one	Teams work around them or demand permanent exceptions	Audit mode first, then enforcement, with an exception process
Everyone is an administrator “to move faster”	No control over the blast radius of a mistake	Roles by job function, traced temporary elevation
Logs collected but never read	Detection in theory only	Targeted alerts and a named owner
Rules configured by hand in the console	Drift and no way to prove the current state	Everything as code, versioned and reviewed
Security handled at the end of the project	Costly fixes, delays	Security and governance from the design stage

How we work with your teams

Scope: assessment, regulatory requirements, priorities. Build: identities, organisation, guardrails and logging. Industrialise: everything moves into code and your pipelines, with automated checks. Improve: periodic reviews, rule adjustments, exception handling.

We work with your infrastructure, security and development teams, and we document every rule with its rationale. A rule that is understood is a rule that is followed.

Who it is for, and when to call us

Small and mid-sized companies whose number of accounts or subscriptions is growing, that are preparing for a compliance requirement (HDS, NIS2, a customer security questionnaire), are coming out of an incident or an audit, or want governance in place before a cloud migration. We work on both AWS and Azure, from Villeneuve-d’Ascq in the Lille metropolitan area (northern France), on site or remotely.

[ YOUR QUESTIONS ]

Frequently asked questions

What is cloud governance?

Cloud governance is the set of rules, roles and controls that frame how the cloud is used: who can create what, where, with which protections and at what cost. It takes the form of an account or subscription structure, automatically enforced policies and review processes.

Who is responsible for security in the cloud?

The provider secures the infrastructure it operates; the customer remains responsible for what it deploys there: identities, configuration, data, application networking. This is the shared responsibility model published by both AWS and Microsoft. Most incidents come from the customer side, notably from overly permissive configurations.

What is the difference between SCPs and Azure Policy?

AWS Organizations Service Control Policies set the maximum permissions allowed in accounts, whatever role is used. Azure Policy evaluates resource configuration against rules and can deny or remediate it. Both act as central guardrails, with different logic, and must be combined with IAM.

Is a cloud security audit enough?

An audit gives a useful snapshot for setting priorities, but configuration changes every day. We favour continuous controls and preventive guardrails, complemented by periodic reviews. The audit then becomes a checkpoint, not the only measure.

Can health data be hosted on AWS or Azure?

Yes, provided you rely on a host certified HDS (Hébergement de Données de Santé, the French certification for hosting health data) for the relevant scope, and put in place the measures that are your responsibility: access control, encryption, traceability, backups. Feekr’s founder has designed AWS infrastructure in this context.