You have built your business in the cloud, leveraging platforms like AWS, Google Cloud, or Microsoft Azure, as you were told the pay-as-you-go service provides you the flexibility to scale up or down depending on usage and the growth of your business.
Everything was going smoothly—until it wasn't. A breach occurs. Who's accountable? The cloud provider? Your contractor development team? Or perhaps, you, the business owner?
Imagine being a tech founder who built a promising SaaS business, and your platform starts to generate revenue and attract investor interest. All of a sudden, your platform has been compromised, with customer data exposed and your reputation hanging by a thread. This is not just a hypothetical scenario — it happens more often than you'd think.
The Reality Check: Shared Responsibility
Many business owners believe that using top-tier cloud services, their applications are fully secure. Unfortunately, this is an illusion, while cloud providers do their best to secure the infrastructure, they are not responsible for securing your application. Let's take a look at what the cloud providers say about this.
AWS:
-
AWS's Responsibility: Security of the cloud. This includes the hardware, software, networking, and facilities that run AWS Cloud services.
-
Your Responsibility: Security in the cloud. This means your customer data, your applications, your identity and access management, and configurations need to be secured by you. If your application running on an EC2 instance is compromised due to misconfigurations or vulnerabilities in your code, it's your responsibility.
Google Cloud:
-
Shared Responsibility: Similar to AWS, Google secures the infrastructure, while you handle your data and applications.
-
Shared Fate: Google introduces this concept to emphasize collaboration. They provide tools, best practices, and configurations to help you with a secured landing zone. However, while Google offers guidance and tools, the responsibility for following the guidance and using the tools to secure your applications and data remains with you.
Microsoft Azure:
-
Azure's responsibility depends on your deployment model:
- SaaS: Microsoft secures everything up to the application layer.
- PaaS: Microsoft secures infrastructure and operating system, but you share the responsibility to secure your application, network controls and identity and directory infrastructure.
- IaaS: Microsoft secures only the physical infrastructure.
- On-premises: You are responsible for everything.
-
Your Responsibility: Regardless of the model, you always remain responsible for securing your data, endpoints, accounts, and access management.
No matter which cloud provider or service model you choose, you cannot shift the responsibility for the security of your own applications, data, and configurations. Cloud security is a shared responsibility — and neglecting your part can lead to breaches and huge financial losses.
The Dangerous Misconfiguration
Many cloud services offered by these cloud providers are extremely useful — but also dangerously easy to misconfigure. A single unchecked setting can leave your platform wide open to attackers. Below are some common mistakes you, as cloud customers, often make:
-
Too Broad Permissions: Assigning "Administrator" access to applications or users who don't need it, dramatically increasing the blast radius if credentials are compromised.
-
Misconfigured Firewalls and Security Groups: Leaving servers exposed to the public internet, allowing direct access to databases, admin dashboards, or internal services that should have been private.
-
Publicly Accessible Storage: AWS S3 buckets, Azure Blob Storage, or Google Cloud Storage buckets configured for public access, exposing customer data, credentials, or internal documents to anyone with a browser.
-
No Multi-Factor Authentication (MFA): Especially on root or administrative accounts — making it trivially easy for attackers to gain full control if they steal a password.
Even if a contractor or outsourced development team sets up your cloud environment, they are not promising you security. Your contractors might have misconfigured your environment — but unless your contract clearly defines liability and responsibility for security, you are still responsible in the eyes of your customers and regulators.
Your cloud provider gives you the infrastructure — but securing how you use it is entirely up to you.
Protecting Your Business in the Cloud
The cloud offers great scalability and flexibility — but security is not automatic.
Misconfigurations, overly broad permissions, unsecured storage, and missing basic protections are all too common — and attackers know exactly where to look.
The good news? Most breaches are preventable with the right security practices and a proactive cybersecurity assessment of your web application and cloud enviroment.
Think about it:
we all pay for health insurance to protect ourselves from unexpected medical costs and do checkups with doctors every year. Yet, too often, we forget to invest in securing the very businesses that generate our income, support our employees, and sustain our future. The risks of neglecting security can be even more costly than you think.
If you're a business owner, founder, or tech leader, securing your cloud setup is not just a technical task — it's critical for protecting your customers, your revenue, and your company's future.
That's where I can support you. I offer a professional cybersecurity assessment service tailored for applications hosted in the cloud. A cybersecurity assessment is a structured security testing in which your web application and cloud environment are analyzed and tested for vulnerabilities, misconfigurations, and potential risks.
Check out my service hereDon't wait for a security incident to find out where your weaknesses are. Book your cybersecurity assessment with me today and take the first step toward more security before attackers do.
FAQ
Defining clear processes for incident reporting is a key part of information security and legal compliance (e.g., under NIS2, ISO 27001, GDPR).
Here is a simple and practical guide to building a clear reporting process:
1. Define What Constitutes a Reportable Incident
First, clarify which events count as security-relevant incidents, for example:
- Data leaks
- IT system outages
- Malware infections
- Suspicious accesses or unauthorized data transfers
Tip: Document concrete examples and thresholds for when reporting is required.
2. Define Responsibilities
- Who must or may report incidents? (e.g., all employees)
- Who receives the reports? (e.g., IT security team, data protection officer)
- Who decides on further steps? (e.g., management, incident response team)
Clearly name roles — for example, in a RACI matrix.
3. Define Reporting Channels and Format
- How should incidents be reported?
- Via email, internal ticket system, phone, special incident mailbox?
- Is there a reporting form?
Tip: Introduce a standardized, easy-to-fill form (digital or paper) with fields like:
- Date/time
- Description of the incident
- Affected systems/persons
- Initial assessment of impact
4. Set Deadlines (e.g., 72 hours according to GDPR)
Within what timeframe must incidents be reported internally and possibly to authorities?
Example:
- For data breaches under GDPR → report to supervisory authority within 72 hours.
- NIS2 also requires timely reporting (e.g., initial assessment within 24 hours).
5. Create a Response and Escalation Plan
- What happens after the report?
- Who analyzes the incident?
- What measures are taken?
- Which internal/external parties must be informed?
Define an emergency plan with escalation levels.
6. Training and Awareness
Regularly train employees on:
- What is an incident?
- How and when to report it?
- What happens afterwards?
Security depends on participation — the clearer and simpler the process, the more likely it will be used.
7. Documentation and Follow-up
- Every incident must be documented (including false alarms!)
- Lessons Learned: What went well, what can be improved?
Keep centralized incident documentation — important for audits and proofs to authorities.
Bonus: What Makes a Process “Clear”?
- Simple & understandable for all employees
- Quickly accessible (e.g., intranet, notice board)
- Responsibilities clearly defined
- Tested in practice — not just on paper
Cloud providers typically offer a range of basic configurations (infrastructure and services) so users can build and manage applications and systems in the cloud.
The main categories are:
1. Compute Resources
- Virtual Machines (VMs):
Virtual machines are software-based replicas of physical computers, allowing multiple operating systems to run simultaneously on one physical machine. - Container Services (e.g., Kubernetes)
- Serverless Functions
2. Storage Services
- Object Storage (e.g., S3):
Object storage stores data as individual, independently managed objects with metadata and unique identifiers. - Block Storage:
Block storage stores data in small, equally sized blocks managed by operating systems like a hard drive. - File Storage
- Database Services (SQL/NoSQL)
3. Networking Services
- Virtual Private Network (VPC)
- Load Balancers
- Domain Name System (DNS)
- Firewalls and Security Groups
4. Security and Identity Management
- Identity and Access Management (IAM)
- Encryption Services
- Logging and Monitoring Services
- Compliance and Audit Tools
5. Developer and Management Tools
- AAutomated Deployment (CI/CD)
- Configuration Management
- Monitoring and Alerting
- Backup and Recovery
Weak Access Credentials and Poor Password Management
- Use of simple or reused passwords
- Lack of multi-factor authentication (MFA)
Misconfigured Cloud Resources
- Open storage buckets (e.g., S3 without access protection)
- Missing or incorrectly configured firewalls and security groups
- Excessive access permissions
Insufficient Monitoring and Logging
- No or incomplete monitoring of unusual activities
- Missing logging of accesses and changes
Outdated Software and Irregular Updates
- Unpatched operating systems and applications
- Security vulnerabilities from outdated components
Lack of Encryption
- Data stored or transmitted unencrypted
- No encryption for data at rest or in transit
Insufficient Backup and Recovery Plans
- Missing or irregular backups
- No testing of recovery processes
No Clear Responsibility and Training
- Unclear responsibilities for cloud security
- Lack of awareness and training of employees about security risks