Cloud security: seven decisions your business still owns

01Define the boundary for each cloud service

The division changes when you move from a virtual machine to a managed database or a ready-made business application. AWS's shared responsibility model explains that customers operating EC2 manage the guest operating system and their applications, while managed services shift different infrastructure tasks to AWS. Treat the selected service, not the word cloud, as the unit of analysis.

Microsoft's responsibility guidance likewise keeps customer data, configurations, and identities on the customer side across its service models. Assign each task to your team, provider, or implementation partner, with a named contact and escalation route.

Check applicable requirements separately from technical responsibility. A provider's certification or selected region does not automatically make your complete application compliant. Data location, support access, subprocessors, contracts, and your own processing may matter under the rules that apply to your organization.

02Control human and application access

Keep company ownership of the cloud account and identity system. Give people individual accounts and roles suited to their tasks. Require appropriate multifactor authentication, especially for administrators, and use phishing-resistant methods where supported. A shared administrator login makes approval, removal, and investigation difficult.

Applications also have identities. A reporting job should not inherit the power to delete production data merely because a developer used an administrator key during setup. Prefer scoped roles and temporary credentials where the platform supports them. AWS's IAM guidance recommends temporary credentials, least privilege, MFA, and regular removal of unused access.

Connect offboarding to the actual access inventory: the identity provider, cloud roles, vendor accounts, source repositories, deployment tools, and long-lived keys. Removing a person's email account does not prove every previously issued credential has stopped working. Check machine identities when a supplier or application changes.

Maintain an emergency access route for an identity-system outage. Limit it, protect it, document when it may be used, and test it under controlled conditions. Record its use and review it afterward. Emergency access that nobody can find is ineffective; an unmonitored permanent administrator account creates another risk.

03Make public exposure an explicit choice

Inventory what is reachable from the internet: the website, API, storage, administrative interfaces, database endpoints, and old test environments. Each public entry needs a reason, an owner, and appropriate controls. A development convenience can become a production exposure when an environment is copied without review.

For storage, inspect the effective access policy rather than relying on an object name that is difficult to guess. Amazon S3 Block Public Access provides controls at several levels. AWS recommends checking application requirements before applying them; a public website and a private customer-document store need different designs.

HTTPS protects a connection in transit. It does not decide which customer may read a record. Test authorization in the application: can one account request another account's invoice, change an identifier, or reach an administrative action? Private infrastructure also needs appropriate identities and application checks.

Treat temporary download links as access mechanisms with a defined scope and lifetime. Consider where the URL may be copied, logged, or forwarded. Keep sensitive links out of unnecessary analytics and support records. Verify expiry and revocation behavior for the actual implementation rather than assuming every signed link behaves identically.

04Protect data, keys, and secrets together

Classify what the application holds and remove data it does not need. Use that inventory to decide access, encryption, retention, backup, and deletion. Production copies in a test environment can bypass the controls your main system has, so use synthetic or appropriately protected test data whenever possible.

Encryption matters, but the ability to use a key is also an access decision. Separate permission to administer encryption settings from permission to read sensitive data where your design supports it. AWS KMS key-policy documentation explains that key policies are a primary mechanism controlling access to KMS keys. Review them alongside the application's permissions.

Store credentials in a suitable secret-management system and limit who or what can retrieve them. Avoid embedding production keys in source code, frontend bundles, shared documents, or logs. Rotation needs a safe update path for the consuming applications; simply generating a replacement is not enough if the old credential remains valid.

Include key availability in recovery planning. A restored encrypted backup is of little use if the required key or identity configuration is unavailable. Test those dependencies together and document who can authorize a sensitive recovery. Retention and deletion choices should follow your business needs and applicable obligations, with jurisdiction-specific advice where required.

05Define recovery and prove it with a restore

Decide how much data the business could afford to lose and how long the workflow could remain unavailable. These are your recovery point objective, or RPO, and recovery time objective, or RTO. A busy order system may need different targets from an internal archive. Set targets before selecting the backup schedule and architecture.

Replication and high availability help with some failures. They are not substitutes for every backup need: a deletion or damaging change may propagate to another copy. Consider separate access boundaries and immutable retention where appropriate, and verify their exact behavior. Protect recovery material against the same credentials or error that could damage production.

Restore into an isolated environment and test the workflow, not only the database status. Check files, keys, configuration, permissions, integrations, and data consistency. Prevent the test from sending real invoices or customer messages. Record the recovery point, elapsed time, validation, missing dependencies, and corrective actions.

AWS Backup restore testing can periodically evaluate restore viability and monitor restore duration for supported resources. The service also provides a validation mechanism. Your business still needs evidence that its application works with the restored resources, along with a cost and cleanup plan for the test.

For the broader transition plan, our cloud migration guide covers migration dependencies. A backup job marked successful and a supplier's promise are useful inputs, but a documented restore is stronger evidence of recovery.

06Decide what to log and who responds

Choose events that help answer operational questions: who changed access, which credentials were used, what exported sensitive data, and when a deployment altered behavior. Review log access and retention, avoid storing secrets or unnecessary personal data, and budget for collection and analysis.

Do not assume every data operation is logged by default. CloudTrail's data-event documentation states that trails and event data stores do not log data events by default; these events can include operations on S3 objects and incur additional charges. Select the needed resources and events deliberately.

Route important alerts to someone who can act, with a backup contact and a response outside normal hours where the service requires it. Start with a manageable set, such as suspicious administrator activity or a critical protection being disabled. A large unread alert queue provides little practical protection.

Rehearse one incident: compromised credentials, accidental public storage, or destructive data change. Confirm how to contain access, preserve relevant evidence, keep business staff informed, and recover safely. External notifications and deadlines depend on the incident and applicable obligations; use the appropriate local process rather than a universal timeline.

07Make security part of routine change

Keep an inventory of services, owners, dependencies, and environments. For each change, identify what must be tested and how to reverse it safely. The provider may maintain its platform while your application dependencies, tenant settings, integration, and user access still require attention.

1. Map the service boundary. List systems, data, suppliers, owners, and the exact responsibilities for the selected services.
2. Inspect access and exposure. Review people, application identities, secrets, public entry points, and permissions with the responsible team.
3. Prove recovery. Restore representative data and dependencies in an isolated environment, then validate the business workflow against your targets.
4. Rehearse and maintain. Test an incident route, fix gaps, and schedule reviews of access, updates, alerts, backups, and ownership.

Use our server and cloud security overview for the wider technical context. If a review finds a material gap, prioritize it with the team that operates the system. Keep evidence and responsibilities current after launch, staff changes, and supplier handovers.

08Questions about business cloud security