The cloud provider secures the infrastructure. Securing the data, the access and the configuration is yours — and that is exactly where most breaches happen.
Done Dynamics performs cloud security audits and hardening work: enumerating the existing cloud account, finding misconfigurations, simplifying the identity and permission structure, secrets management, logging and monitoring design, backup verification, and clarifying data residency for compliance purposes. The work is not tied to a single provider; the same control set is applied on AWS, Cloudflare, Hetzner, Google Cloud and comparable platforms.
The starting point of this page is the shared responsibility model. The cloud provider protects the data centre, the hardware and the virtualisation layer — and that side is genuinely done well. But which resource in your account faces the internet, who can reach what, whether the data is encrypted and where the keys live all stay with you. This is where we meet the most common misunderstanding in the field: the sentence "it is in the cloud, so it is safe" treats a responsibility that was never handed over as if it had been.
The audit runs with read-only permissions, production is not touched, and the output is a finding list ordered by severity. The work can run as part of a broader cyber security engagement or on its own; when it is planned alongside the hosting layer it is consolidated with hosting services into the same document.
Every conversation about cloud security should start from this line: where is the boundary, and who is on which side of it.
Physical data centre security, server hardware, the virtualisation layer and the infrastructure network are the cloud provider's responsibility. That side is genuinely done well: a level of protection no mid-sized organisation could build alone comes included in the rental price. This is not where the problems come from.
Who your accounts are open to, which resource faces the internet, whether data is encrypted, where the keys live and who can delete what remains entirely with the customer. The provider does not make these settings safe on your behalf; it only hands you the tools with which you can make them safe.
On a rented server the operating system patches are yours; on a managed database the patches are the provider's but the access policy is yours; in a software service the configuration and user management are yours again. If one organisation uses three service types, it has three different responsibility lines, and they need to be written down.
The sentence we hear most in the field is this: "It is in the cloud, so it is safe." That sentence assumes responsibility has been handed over, when only the infrastructure layer has. The large majority of data leaks happen not because the provider's infrastructure was broken, but because the customer's configuration was left loose.
The large majority of cloud incidents come not from a sophisticated attack but from a setting left open. These are the six patterns we find most often in the accounts we take over.
A bucket is made public one afternoon to share some backup files, and nobody remembers to close it. Inside there may be customer records, a database dump or an invoice archive. These buckets are scanned continuously across the internet; being found takes minutes, not hours.
A database port opened during development so someone can connect from outside stays open in production. Scanning bots try known ports constantly; when a weak or default password is found, the login, the leak and the ransom demand can all happen on the same day.
Management interfaces, monitoring dashboards and queue consoles brought up quickly during setup usually keep their installation password. These panels typically grant access to the whole server and are often discoverable through search engines.
An "any port from anywhere" rule added to a security group to solve a problem quickly is never removed once the problem is gone. On its own that single rule cancels out all cloud network segmentation; every server behind it ends up facing the internet directly.
A test environment opened for a project is not shut down when the project ends. It stays up for months with a copy of production data, unpatched software and loose access rules. For an attacker, this is very often the shortest path into production.
Disk snapshots and machine images can be marked as shareable. A publicly shared image contains embedded keys, configuration files and database contents. This is a silent leak that can run for years without anyone noticing.
What these six have in common is that none of them come from bad intent. Every one is a temporary decision made to get something done quickly, and none of them were undone. The first job of the audit is to find and list those temporary decisions.
In the cloud, identity has largely taken the place the firewall used to hold. Compromising one account can carry far heavier consequences than compromising one server on a classic network — because everything that identity can create, delete and read becomes reachable at once.
All eight points come back to one question: if this identity were compromised today, what would the attacker reach?
A meaningful share of attackers who get into a cloud account never break the door down; they find the key on the ground and use it.
API keys, database passwords and cloud access keys leak most often through code repositories. Deleting the key in the next commit is not enough — it remains in the history. If the repository was ever public, revoking the key is the only correct answer.
An environment variable is a step forward because it separates the key from the code; but it can still appear in process listings, log files and error traces. For critical keys a secrets vault is used: access is authorised, every read is recorded, and the value can be changed centrally.
Public code repositories are scanned continuously. What we see in the field is that a leaked cloud key starts being used long before anyone notices it — usually to spin up resources. That is why a key leak is the subject of that hour, not of the next meeting.
What happens when a key is suspected of leaking is written in advance: where that key is used, which service stops if it is revoked, and how the replacement is distributed. If that procedure is not written down, the revocation decision is delayed, and the delay is what makes the damage larger.
In the cloud the network is configuration, not cable. That means one wrong line can remove all segmentation — and that it can be restored just as easily.
Cloud security groups bloat over time exactly like classic firewall rule bases. Each rule gets a reason, an owner and a date; the source range is kept as narrow as it can be. "From anywhere" is used only for services that genuinely must be open to everyone.
Databases, internal services and job queues do not sit in an internet-facing subnet. They move to a private subnet; if they need outbound access it is granted through a controlled gateway. That way even a mistaken security group rule cannot expose them directly.
Shell access, database clients and admin panels are not left open to the internet. They go behind a VPN or an authenticated access layer. This single change removes most of the noise scanning bots generate, and the risk that arrives with it.
Most deployments inspect inbound traffic and leave outbound wide open. Yet data exfiltration and malware talking to its command server both happen on the way out. Which addresses and ports servers may reach externally is restricted deliberately.
Object storage, secrets vaults and managed databases can be reached over the provider's internal network rather than the public internet. This keeps the traffic from leaving and makes the access restrictable at the network level.
Encryption is close to a free control in the cloud — a handful of settings and one design decision. Even so, it is one of the layers we most often find missing in the deployments we take over, particularly on the backup side.
A cloud audit log cannot be enabled retroactively. If it is off, no evidence exists for that period once an incident happens. That makes logging design one of the few irreversible decisions taken before anything goes wrong.
The provider not losing your data and you being able to get your data back are two different things. The second one needs its own design.
The provider's infrastructure is durable — your disk will not fail, your server will not vanish. But that is not a backup. A table deleted by accident, a bad deployment or a disk encrypted by ransomware all need a separately taken backup, and taking it is your job.
When a server or database is deleted, most providers offer no recovery window. Deletion protection, tagging critical resources and restricting delete permissions to a small group all reduce this risk. Deletions are also logged.
A backup should not sit in the same place as the event it protects against. A backup inside the same account does not help in an account-compromise scenario. Copies go to a different region and, where possible, to a different account with write-only permissions.
An untested backup is not a backup. A real restore is performed at set intervals; how long it takes is measured and written down. If the measured time does not match the downtime the organisation can tolerate, the backup design changes.
The region chosen while opening a cloud account is usually a dropdown nobody stops to think about. Yet that dropdown decides in which country personal data will be processed, and under the Turkish data protection law the transfer abroad begins at that moment.
The output of this section is a technical finding, not a legal opinion: where the data actually sits, which copies leave for where, and whether any of it is documented.
In the cloud, the first visible symptom of a security incident is often not an alert but an unexpected invoice. That is why cost controls count as security controls.
The audit runs in five steps. Each step produces a written output that becomes the input of the next.
Which accounts, which regions and which services will be audited is written down. A read-only role is defined for the audit; no permission that can change anything is requested. How access is granted and how it will be withdrawn at the end is agreed up front.
Every resource in the account is enumerated: machines, storage, databases, identities, network rules and keys. Common misconfiguration patterns are scanned with automated checks. The output of this step is a raw finding list.
Automated scanning produces false positives. Every finding is verified by hand: is it really reachable, what data does it expose, is there a business reason behind it. An unverified finding does not reach the report.
Findings are ranked by severity. Each one records the impact, how it was verified and the remediation step. The report comes in two layers: detailed for the technical team, a one-page summary for management.
Fixes are planned in priority order; organisations that prefer to apply them with their own team can, and those that prefer to hand them over can. Once remediation is complete the same checks are run again and closed findings are marked in a separate document.
The audit is a fixed-price project; its scope is set by the number of accounts, the number of regions and the breadth of services in use. The scoping conversation is free and ends with a one-page quote — what is included and what is not are on the same page. Remediation is quoted separately and is not mandatory: an organisation that takes the report and applies it with its own team incurs no extra cost. For those who want periodic re-auditing and continuous monitoring we define a monthly service: checking newly created resources, keeping the identity inventory current, following up budget alerts and re-scanning every three or six months all run under that scope. Usage fees paid to the cloud provider are always passed through at cost, with no markup. The audit output — the report, the inventory tables and the checklist — stays with the organisation; we do not have a working model that keeps them on our side.
We work mainly on AWS, Cloudflare, Hetzner and Google Cloud, and we also audit platforms such as Azure and DigitalOcean. The concepts are the same regardless of provider: identity and authorisation, network boundaries, storage access, encryption, logging and backup. What changes is the naming and the interface. For organisations using more than one provider the audit is consolidated into a single report, because the real risk usually appears where two platforms meet — for example a key stored on one platform that grants access to the other.
The audit is performed on the existing setup; a rebuild is not required, and in most cases not recommended either. A cloud account that has grown over the years is valuable precisely because it carries running work. Our job is not to tear it down but to establish why each setting is the way it is and to put the risky ones in order. A rebuild is only suggested when the account structure is fundamentally broken — for example when production and test are tangled together in one account — and even then the migration is planned in stages.
For a single-account setup with a limited number of resources, inventory and scanning take a few days and manual verification plus reporting take about a week. For multi-account setups running across several regions the timeline can stretch to two or three weeks. The main variable is not the number of resources but the complexity of the identity and permission structure: reviewing a hundred servers takes less time than untangling forty interlocking roles. Once the scope is settled the timeline is given in writing.
No. The audit runs with read-only permissions; nothing is reconfigured, no resources are created, no data is downloaded. Load testing or attack simulation sits outside this scope and only happens on separate request, with written permission and in a planned window. Read operations are paced so as not to strain the provider's API limits. Once remediation begins, each change is planned individually, a rollback step is written beforehand, and anything that could affect production goes into a maintenance window.
Using the cloud is not in itself a source of non-compliance. Türkiye's data protection law asks not where data sits but how it is protected and how transfers are documented. In practice we look at three things: is the physical location of the data known, if there is a transfer abroad is its rationale and legal basis written down, and has the processor and sub-processor chain been mapped. If those three are in place, cloud use does not conflict with compliance. Keeping data in Türkiye is technically possible and in many scenarios noticeably reduces the compliance workload, which is why that decision is weighed openly against cost and service breadth.
A read-only audit role. Most providers ship a ready-made policy for this; where they do not, we define a role covering the required read permissions together with you. The role is attached to time-limited access rather than a permanent user and is removed when the audit ends. You perform the removal; we do not have to ask for it. When access is granted we state item by item which permissions are being requested — we do not have a working model that starts with "give us full access and leave the rest to us".
The report is prepared in two layers. The management summary is one page: how many findings there are, how many are critical, what the three biggest risks are and the estimated effort to remediate. The technical section covers each finding individually — which resource it affects, how it was verified, what the impact would be if exploited, and the remediation step. Findings are classified as critical, high, medium or low, and the classification is based on reachability and impact rather than theoretical severity. Areas we found correctly configured are written down as well, because knowing what is already in place is the starting point for the next audit.
The audit is a fixed-price project; its scope is set by the number of accounts, the number of regions and the breadth of services in use. The scoping conversation is free and ends with a one-page quote — what is included and what is not are written on the same page. Remediation work is quoted separately and is not mandatory: an organisation that takes the report and applies it with its own team incurs no additional cost. For organisations wanting continuous monitoring and periodic re-auditing we define a monthly service model. Usage fees paid to the cloud provider are always passed through at cost, with no markup.
Optionally. Some organisations take the report and apply it with their own team; that is entirely workable, because the report writes remediation steps at a level you can act on. Where the work is handed to us, each change is planned separately, a rollback step is prepared in advance, and anything that could affect production goes into a planned window. Retesting after remediation happens either way; we do not mark a finding closed when we can see it has not closed.
Yes, and the return is often higher on small setups. Fewer resources means the audit is short and the findings close quickly. What we see in the field is this: small deployments have fewer findings but a higher share of critical ones — because the setup was usually done by one person, quickly, with a "we will fix it later" that never arrived. For an organisation with a handful of servers the audit usually takes a few days, and a good share of the findings can be closed in the same week.
Related services
Penetration testing, vulnerability scanning and incident response — the on-premise and application counterpart of the cloud audit.
Segmentation, firewall rules and VPN — the design of the place where the cloud and the corporate network meet.
Server setup, certificate management, monitoring and patch scheduling; the layer where audit findings actually get fixed.
A backup architecture built on cross-region copies, a retention policy and regular restore testing.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.