Security Questions to Ask Before Moving an App to the Cloud

TL;DR — Moving an application to the cloud does not automatically make it more secure; it changes who is responsible for which parts and creates new places to misconfigure access. The single most useful step is to review the move using a short security checklist: who can log in, where data is stored, what is exposed to the internet, how backups work, and how you would detect and recover from a problem. Reading time: ~7 min

What it is and where it sits

This is not one security control. It is a decision framework you use before migration so you do not discover security gaps after the app is live.

When a team says "we're moving to the cloud," they usually mean some combination of these changes:

• the application servers move from an office or private data center into a cloud provider account
• the database moves to a managed service (a hosted database run by the provider)
• file storage moves to object storage (internet-accessible storage for files and backups)
• login may move to a central identity provider or "IdP" (the system that handles sign-in)
• traffic starts passing through cloud networking, load balancers (traffic distributors), and DNS (the phonebook of the internet)

The security questions sit across that whole path. They are about who talks to what, from where, using which credentials, and what happens if something goes wrong.

A typical request flow looks like this:

[Customer Browser] ---- 1. HTTPS request ----> [DNS/CDN]
[DNS/CDN] ---- 2. forward ----> [Load Balancer]
[Load Balancer] ---- 3. send request ----> [App Server]
[App Server] ---- 4. query ----> [Database]
[App Server] ---- 5. read/write ----> [Object Storage]
[Team Member] ---- 6. admin login ----> [Cloud Dashboard]
[Cloud Dashboard] ---- 7. control plane ----> [Cloud Resources]

Before the move, some of these may have lived in one place: a single server, a VPN (private network tunnel), a local file share, and a company firewall. After the move, they are separate services with separate permissions. That is why the right security questions matter more in cloud projects than many buyers expect.

The core questions to ask

Ask your agency or internal team these, in plain language:

1. What data are we moving, and how sensitive is it? Customer records, payment data, health data, internal documents, logs?
2. Who can access production, and how do they sign in? Named accounts with MFA (multi-factor authentication), or shared passwords?
3. What parts will be public on the internet? Website only, or also database admin pages, storage buckets, and dashboards?
4. How are secrets stored? API keys, database passwords, SMTP credentials, encryption keys?
5. How are backups created, tested, and restored? Not just "we take backups" but "show the restore process."
6. How will we know if something bad happens? Logs, alerts, failed login notifications, unusual data export alerts?
7. What is the provider responsible for, and what are we still responsible for? This is the shared responsibility model (the split between provider security and customer configuration).
8. What is the exit plan? If you leave the provider or agency, how do you get data, configs, and access back?

How it actually works

The mechanism is simple: each cloud component gets its own access rules, encryption settings, logging, and backup plan. Security comes from setting those controls deliberately before cutover.

One realistic example: moving a customer portal to the cloud

Imagine a customer portal with:

• a web app
• a Postgres database
• uploaded PDF files
• email sending for password resets
• an admin area used by staff

Here is the step-by-step security review before migration.

1. Identify the assets. The team lists: customer names, email addresses, invoices, uploaded PDFs, and admin actions. This tells you the database and file storage need stronger controls than a marketing site.

2. Decide internet exposure. The public website and customer login page must be reachable from the internet. The database must not be directly reachable from the internet. Admin tools should either require company SSO (single sign-on) or be restricted by IP allowlist (a list of approved office/VPN addresses).

3. Set up identity first. In the cloud provider's dashboard, create named user accounts for each staff member. Turn on MFA in the provider's security or identity section. Do not let the agency keep one shared "admin" login for everyone.

4. Create separate environments. Production, staging, and development get separate accounts or at least separate projects. This reduces the chance that a test script deletes production data.

5. Move secrets into a secret manager. Instead of putting database passwords into a shared spreadsheet or .env file emailed around, store them in the provider's secret manager or your deployment platform's encrypted environment variable section.

6. Encrypt data in transit and at rest. HTTPS is enabled for the website. Database connections use TLS (encrypted transport). Storage encryption at rest is enabled in the provider settings.

7. Turn on logs and alerts. Enable access logs for the load balancer or web tier, database audit logs if available, and cloud activity logs for admin actions. Create alerts for failed admin logins, deleted backups, and changes to firewall rules.

8. Define backups and test restore. Daily database backups are scheduled. File storage versioning (keeping older file versions) is enabled if available. Then the team performs one restore into staging and confirms the app starts.

9. Cut over DNS. Only after the above is ready does the team point the domain to the cloud app.

10. Review after go-live. In the first week, check logs, verify backups ran, and confirm no storage bucket or database was accidentally exposed.

That is how cloud security works in practice: not one magic setting, but a chain of small, concrete controls.

When to use it (and when not to)

You should use this question set before any move that changes hosting, identity, storage, or operations.

You probably don't need a heavy process if...

• the site has no login, no customer data, and no admin editing beyond a simple CMS
• the move is temporary and the system contains only public, non-sensitive content
• you are buying a standard SaaS product where you do not control servers, databases, or networking

Even then, still ask about MFA, backups, domain control, and who owns the account.

Trade-offs

Cloud security controls bring real benefits, but each one costs something.

• Benefit: better access control with named accounts and MFA
  Cost: more setup, more user management, occasional login friction.

• Benefit: private databases and locked-down networks reduce exposure
  Cost: more architecture work, harder troubleshooting, possible need for bastion hosts (jump boxes) or VPN access.

• Benefit: managed databases and storage often improve baseline security
  Cost: provider lock-in, feature differences, and less low-level control.

• Benefit: encryption and secret management reduce credential leakage
  Cost: key rotation and deployment processes become more disciplined.

• Benefit: logs and alerts improve detection
  Cost: extra monthly charges, noisy alerts if configured badly, and someone must actually review them.

• Benefit: separate staging and production reduce accidental damage
  Cost: more environments to maintain and pay for.

• Benefit: tested backups reduce disaster risk
  Cost: storage fees, restore drills, and the uncomfortable time needed to verify recovery.

The key decision is not "cloud or no cloud." It is whether your team is willing to operate the controls the cloud gives you.

In practice

Below are two examples you can adapt or ask your agency to implement.

Example 1: nginx config to force HTTPS and add basic security headers

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

This redirects all HTTP traffic to HTTPS and adds a few common browser security headers. The gotcha: only enable Strict-Transport-Security after HTTPS is working correctly on all subdomains you include, or you can lock users into a broken HTTPS path.

Example 2: Postgres role setup to avoid using one superuser for the app

⚠️ Running SQL permission changes on the wrong database can break your application or lock out admins. Do this first in staging, then apply to production during a planned maintenance window if your team is not used to role changes.

CREATE ROLE app_login LOGIN PASSWORD 'replace-with-generated-secret';
CREATE ROLE app_rw;
GRANT CONNECT ON DATABASE customer_portal TO app_rw;
GRANT USAGE ON SCHEMA public TO app_rw;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;
GRANT app_rw TO app_login;

This creates a login role for the application and grants only normal read/write access instead of full database admin rights. The gotcha: existing sequences and future tables may need additional grants depending on your schema and migration tool.

Dashboard actions to ask for explicitly

If you do not manage servers yourself, ask your agency to show you these exact places in the provider dashboard:

• Identity/Security section: turn on MFA for all admin users
• Networking or Firewall section: confirm the database allows traffic only from the app, not from 0.0.0.0/0 (all internet addresses)
• Storage section: check whether any bucket/container is marked public
• Backups section: show backup schedule, retention period, and the restore button or restore workflow
• Audit/Activity Logs section: confirm admin actions are being recorded

If the agency cannot show where those settings live, that is itself useful information.

Further reading

• NIST SP 800-144, "Guidelines on Security and Privacy in Public Cloud Computing"
• OWASP Application Security Verification Standard (ASVS)
• The "Shared Responsibility Model" documentation from your cloud provider
• The "Transport Layer Security (TLS)" article in the MDN Web Docs security section
• PostgreSQL Documentation: "Role Attributes" and "GRANT"

This article was written by an AI system and published pending human review. Verify anything you intend to act on.