Secure Cloud Hosting for Compliance: A Practical Guide for Startups and Regulated Industries

Last updated: October 28, 2026

Compliance requirements shape infrastructure decisions. Teams building in healthcare, finance, and enterprise SaaS face a practical question: can managed cloud platforms satisfy regulatory frameworks, or does compliance require self-managed infrastructure? The answer depends on understanding what each framework actually requires, what responsibilities shift to your provider under a shared responsibility model, and what controls you retain regardless of where your workloads run.

TL;DR

• SOC 2: Review your host's control evidence; you still own your application's controls and your organization's examination. Source: AICPA.
• HIPAA: A host handling electronic protected health information needs an appropriate Business Associate Agreement (BAA) and safeguards; you still own your risk analysis and application safeguards. Source: HHS.
• GDPR: Assess your host's processing terms, security, and international transfers; you still own lawful processing, individual rights, and retention decisions. Source: EDPB's data protection guide.
• PCI DSS: Verify hosting controls for the systems in your payment scope; you still own integration security and confirming your assessment obligations. Source: PCI SSC.
• ISO 27001: Evaluate hosting controls within your information security management system; you still own risk assessment, risk treatment, and certification scope. Source: ISO.

This guide addresses the specific questions that arise when evaluating cloud hosts for regulated workloads. The focus is on mechanisms and requirements rather than product comparisons. Here are the questions this post addresses:

• Can you get SOC 2 compliant without self-managing servers?
• What does the cloud provider handle vs what do I handle?
• What does a SOC 2 auditor ask a startup on a PaaS?
• What should a GDPR data processing agreement include?
• Does GDPR require EU data residency?
• How do you encrypt secrets and customer data across a multi-region PaaS?
• How do you automate vulnerability scans and patching in CI/CD?
• How do you make audit logs for deploys and database queries tamper-resistant?
• Is dedicated tenancy necessary for ISO 27001 on managed runtimes?
• Can a fintech MVP stay PCI-DSS compliant on serverless infrastructure?
• Can you run HIPAA workloads in containers on a PaaS?
• What are best practices for role-based access control on a serverless stack?

Yes. You can pursue SOC 2 compliance on managed hosting without self-managing servers, but your provider’s report does not cover your own application and organizational controls. AICPA’s SOC guidance explains how assurance reports support assessment of outsourced services.

SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy; agree on the categories in scope with your auditor.

The audit examines whether controls exist and, for Type II reports, whether they operated effectively over a review period. When you deploy on a managed platform, some controls fall under your provider's scope and some remain yours.

A managed host operates the infrastructure layers included in its service; you retain application security and your own organizational controls. The following split is illustrative: confirm the exact scope in the provider’s report and agreement.

A cloud host's SOC 2 report covers their infrastructure controls. Your auditor will want to see this report to understand the environment your application runs in. Request the full Type II report, not just the SOC 3 summary, since Type II includes the auditor's detailed testing results.

Platform capabilities to evaluate:

• Audit logs that capture deployment events and access
• Granular team permissions with role-based access control (RBAC)
• Environment separation between staging and production
• Encryption at rest meeting your auditor's requirements
• MFA enforcement for team members
• SSO integration for centralized identity management

The platform's own audit status matters, but your ability to configure and evidence your controls on top of it matters equally.

Railway’s compliance documentation directs customers to its Trust Center to request the security audit.

Your auditor will ask for evidence of the controls your organization operates, alongside the provider evidence relevant to your system. Actual requests depend on your examination scope; use these questions to prepare:

• Who has access to production, and when was that access last reviewed?
• How are code and configuration changes approved before deployment?
• How are vulnerabilities identified, assigned, and remediated?
• Which provider controls do you rely on, and which customer controls must you implement?
• How do you protect sensitive data and record access to it?

Keep access-review records, approved pull requests, deployment records, remediation tickets, and your provider-report review together. These are practical evidence examples for the control areas covered by AICPA’s Trust Services Criteria, rather than a universal auditor checklist.

A data processing agreement should define the processing, the data involved, and the processor’s obligations, including subprocessor arrangements, audit support, and deletion or return of data. The EDPB’s controller and processor guidance explains the contract requirements.

DPA checklist for GDPR Article 28 compliance:

• Nature and purpose of processing specified
• Data categories defined
• Processor obligations regarding subprocessors documented
• Audit rights included
• Data deletion procedures specified
• Subprocessor notification/consent process defined

Ask for the subprocessor list. The list should include each subprocessor's identity, location, and processing purpose.

Railway’s Trust Center publishes a subprocessor list for this review.

[IMAGE PLACEHOLDER 2: Railway Trust Center: subprocessor list]

No. GDPR does not impose a blanket EU-only data residency requirement; transfers outside the European Economic Area must meet applicable transfer rules. The EDPB explains the available transfer mechanisms. Sector-specific regulations and customer contracts may impose stricter storage or processing locations.

Start by distinguishing between data residency and data sovereignty:

When evaluating a platform for EU data residency, examine five data flows:

[IMAGE PLACEHOLDER 3: Diagram: five data flows to review for EU residency]

For each data flow, verify:

1. Application data at rest

• Platform offers EU regions
• Deployments can be pinned to specific regions
• Region selection is per-service (a single US database breaks residency)

2. Application data in transit

• CDN routing is configured to prefer EU edge locations for request handling.
• Load balancers operate within region
• DDoS mitigation does not route through US infrastructure

3. Backups and disaster recovery

• Backup storage location is documented
• Cross-region replication can be disabled or constrained
• Point-in-time recovery stays within region

4. Logs and observability data

• Logging infrastructure offers region selection
• Metrics and traces stay within region
• Error tracking does not export data externally

5. Subprocessor data flows

• Subprocessor list includes locations
• Transfer mechanisms documented (DPF, SCCs)
• You can identify which subprocessors receive personal data

For strict EU-only requirements, you need a provider that can demonstrate all five data flows meet that commitment. If exceptions are permitted, document them and assess the applicable transfer safeguards; safeguards alone do not override an EU-only contract.

Protect data in transit, at rest, and wherever secrets are exposed, using controls appropriate to your framework and risk assessment. The following checklists are implementation recommendations, not identical requirements across every framework; HHS’s Security Rule summary explains the risk-based approach for ePHI.

• TLS 1.2 minimum enforced (TLS 1.3 preferred)
• TLS 1.0, 1.1, SSL disabled
• Failed TLS negotiation results in connection failure (no fallback)
• Internal service-to-service traffic encrypted
• Database connections use TLS
• HTTPS-only enforced for public endpoints

• Strong encryption used (for example, AES-256), appropriate to the applicable requirements
• Application volumes encrypted
• Database storage encrypted
• Backups encrypted
• Logs encrypted
• Keys managed via KMS with access controls
• Key rotation supported
• Data deletion and any cryptographic erasure procedures documented

Secrets exposure points to verify:

• Build logs (should not contain secrets)
• Deployment logs (should not contain secrets)
• Debugging interfaces (should not expose env vars)
• Error messages (should not include credentials)

Automate scans in CI/CD, track remediation, and retain evidence of both detection and fixes. Vulnerability management has two components: identifying vulnerabilities and remediating them; AICPA’s Trust Services Criteria provide relevant control areas. Confirm the provider’s maintenance scope rather than assuming it covers the images you deploy.

Here’s an example using dependency-review-action to reject pull requests introducing high-severity vulnerabilities. It requires the dependency graph to be enabled and an eligible repository; check the action’s documented availability for private repositories. Configure the resulting check as required if it should block merging.

# .github/workflows/dependency-review.yml

name: Dependency Review

on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

These are example internal policy targets, not deadlines mandated across all frameworks. Adjust them to your exposure, risk assessment, and applicable requirements.

Evidence to retain for audits:

• Scan results (what was detected)
• Timestamps (when detected)
• Remediation records (how and when fixed)
• Coverage proof (all components scanned)

Questions to ask your provider about their patching:

1. What is the SLA for critical vulnerability patches?
2. How are patches deployed? (Rolling updates requiring no customer action is ideal)
3. Are patch events communicated to customers?
4. Is there a security advisory feed or status page?

Capture the actor, action, target, and time, then protect log integrity and retention separately from the application. HHS identifies audit controls as a technical safeguard.

Audit logging serves two purposes: detecting unauthorized activity and providing evidence for compliance audits. Both require logs that are comprehensive, timely, and trustworthy.

Platform-layer events to log:

Application-layer events to log:

Database query logging requires balancing coverage against storage and performance costs. A practical approach is to capture high-risk access while sampling routine traffic only where your audit requirements allow it. Record query metadata without copying sensitive payloads unnecessarily.

Always log:

• Slow queries
• Errors
• Queries on PHI or sensitive tables
• Admin connections
• DDL statements
• DELETE/UPDATE on sensitive tables

Consider sampling:

• Normal SELECT queries
• Read-only connections
• High-volume endpoints

The goal is not comprehensive query capture but the ability to reconstruct who accessed what data and when.

• Logs stored separately from systems being logged
• Developers can read but not delete audit logs
• Retention meets your applicable framework and contractual requirements
• Log deletion can be disabled during retention window
• Logs hashed or signed for integrity verification

Platform logs and application logs should flow to a centralized SIEM (Security Information and Event Management) or log store. Many managed platforms include built-in log storage and viewing, which may be sufficient for early-stage compliance needs. As you scale or require longer retention, cross-source querying, or advanced alerting, export logs to a dedicated SIEM like Datadog, Splunk, or Elastic. The key is having a single location where you can query across platform and application logs when reviewing activity and providing audit evidence.

High-priority alerts to configure:

• Failed login attempts above threshold
• Deployment outside business hours
• Permission changes
• New API key creation
• Access from unusual locations
• Bulk data exports

No. ISO 27001 does not universally require dedicated tenancy. ISO 27001 is a management system standard. It requires organizations to identify information security risks and implement appropriate controls. It does not prescribe specific technical implementations such as dedicated tenancy.

Shared tenancy with appropriate isolation can fit an organization’s risk treatment. Evaluate the provider’s isolation evidence and your contractual obligations rather than assuming that shared or dedicated infrastructure establishes compliance.

You may need dedicated tenancy when:

• Customer contracts explicitly require it
• Government or defense workloads
• Highly regulated sectors with specific isolation mandates
• Maximum isolation is a business requirement

The key is documenting your decision and risk assessment. Document how the tenancy choice fits your risk assessment and treatment plan.

What to verify about shared tenancy isolation:

• Workloads run in isolated containers or VMs
• Separate network namespaces
• Separate storage volumes
• Separate process spaces
• Provider's SOC 2 describes and audits isolation mechanisms

The decision depends on your specific risk profile and obligations.

Yes, provided the environment meets the applicable requirements. PCI-DSS (Payment Card Industry Data Security Standard) compliance depends on how you handle cardholder data. The scope of your compliance obligations narrows dramatically if you never store, process, or transmit card numbers directly.

PCI scope comparison:

PCI SSC confirms that qualifying iframe integrations can use SAQ A, with specific script-security eligibility guidance for embedded payment forms. Confirm the assessment with your acquiring bank or other entity managing validation; each SAQ has specific eligibility criteria.

For reduced-scope (tokenized) compliance, verify:

• Card numbers never touch your infrastructure
• Payment processor’s current PCI DSS validation covers the service you use
• API keys for payment processor are secured
• Application does not log or store card data accidentally
• Error messages do not expose card details

Clarify your scope before making infrastructure decisions.

Yes, when the services handling electronic protected health information (ePHI) are covered by appropriate BAAs and your deployment meets applicable HIPAA requirements. HHS’s cloud computing guidance explains the shared responsibilities. HIPAA compliance for these cloud deployments requires a Business Associate Agreement (BAA) between you and your cloud provider. Without a BAA, you cannot use the platform for PHI (Protected Health Information) workloads regardless of its security controls.

• BAA executed before deploying PHI
• Encryption at rest for all PHI storage
• Encryption in transit for all PHI transmission
• Access controls limit PHI to workforce with legitimate need
• Audit logging captures PHI access
• Backup and recovery procedures documented
• Policies and procedures address protection of PHI

Some providers restrict support access when a BAA is in effect to avoid exposing PHI during troubleshooting. Understand these restrictions before signing.

Apply least privilege through team permissions, environment separation, and service-level secrets. Role-based access control on a managed platform can operate differently than on self-managed infrastructure; function-level IAM may not be available. Instead, you work with the platform's team permissions, environment separation, and service-level secrets. The goal remains least privilege, but the mechanisms are different.

Separate production and staging at the project level

Most PaaS platforms scope permissions to projects or workspaces. If your platform only offers broad roles (admin/member) without environment-level granularity, create separate projects for production and staging. This lets you give engineers full access to staging while restricting production access to a smaller group.

[IMAGE PLACEHOLDER 4: Screenshot: production and staging access separation]

Each service should have access only to the secrets it needs. A background worker processing jobs should not have access to your Stripe API key if it never handles payments. On platforms where environment variables are set per-service, this is straightforward. On platforms where environment variables are shared across a project, you need to be more deliberate about what you expose.

Common mistakes:

• Sharing a single database connection string across all services when some only need read access
• Giving every service access to third-party API keys "for convenience"
• Using the same credentials for staging and production services

CI/CD pipelines need credentials to deploy. These tokens are service accounts and should follow the same principles:

• Create separate tokens for staging and production deployments
• Scope tokens to the minimum permissions needed (deploy, not team management)
• Store tokens in your CI/CD platform's secrets management, not in repository code
• Rotate tokens on a schedule and immediately when engineers with access leave
• Audit token usage for deployments you don't recognize

If your platform offers project-scoped or environment-scoped tokens, use them. A token that can deploy to staging should not be able to deploy to production.

Platform-level MFA is useful but limited. If your team authenticates through an identity provider (Okta, Azure AD, Google Workspace), enforce MFA there. This gives you:

• Consistent MFA policy across all tools, not just your deployment platform
• Conditional access rules (require MFA for production access, allow remembered devices for staging)
• Centralized audit logs for authentication events
• Automatic access revocation when someone leaves the organization

For platforms supporting SAML, enable it and consider enforcing SAML Strict Mode to prevent users from bypassing SSO with direct login.

Set an access-review cadence appropriate to your obligations and risks; quarterly is a useful example. AICPA’s Trust Services Criteria address access controls and their review. Ask specific questions:

• Who has access to production? For each person, what is the business justification?
• What deployment tokens exist? Which CI/CD pipelines use them? Are any orphaned?
• Who has access to view or modify secrets? Is this the same list as production deploy access, or broader?
• Have any contractors or former employees retained access?
• Are there any shared accounts or credentials that multiple people use?

Document the review and any changes made. This documentation is audit evidence.

On raw serverless infrastructure (e.g. AWS Lambda with IAM), you can assign each function its own IAM role with specific permissions. A function that reads from S3 gets s3:GetObject on specific buckets. A function that writes to DynamoDB gets dynamodb:PutItem on specific tables. This is fine-grained but operationally complex.

On a managed PaaS, you typically don't get function-level IAM. You get service-level separation: each service has its own environment variables, its own network identity, and its own scaling. The practical approach is to treat each service as a permission boundary. If two pieces of code need different access levels, deploy them as separate services rather than trying to manage permissions within a single service.

The tradeoff is coarser granularity in exchange for simpler operations. For most teams, this is the right tradeoff. If you need function-level IAM policies, you're likely building on raw cloud infrastructure rather than a managed platform.

Choose based on the controls you need and the infrastructure work your team can sustain. These are practical recommendations; no hosting model makes an application compliant by itself.

Best for: Teams that want managed deployments and infrastructure operations, and can meet their requirements within the platform’s documented controls and agreements.

PaaS reduces the infrastructure your team operates, leaving more attention for application controls and evidence. Verify service scope, agreements, and access boundaries before placing regulated data on the platform.

Best for: Teams that need a broad service catalog and detailed infrastructure configuration, with the expertise to configure and evidence those controls.

Hyperscalers offer both managed services and infrastructure primitives. Compare the actual services you will use: operating responsibilities vary substantially between them.

Best for: Teams with specific isolation or configuration requirements and the staff to operate, secure, and document the stack.

Direct control comes with responsibility for infrastructure maintenance and evidence. Choose it when those configuration options meet a concrete requirement.

Railway provides SOC reports, HIPAA BAAs, and a GDPR DPA to support compliance reviews. Its compliance documentation describes these offerings and its work with teams in healthcare, finance, and government; audit, security, and regulatory documents are available through the Trust Center.

For HIPAA workloads, Railway offers Business Associate Agreements as an add-on. When a BAA is in effect, Railway team members can no longer directly access running workloads.

The GDPR DPA can be executed through the self-service link in Railway’s compliance docs. A subprocessor list is published in the Trust Center, including Stripe for billing, Cloudflare for CDN, and Google Cloud for infrastructure.

The Trust Center lists the following reports; use its access process for restricted documents:

• SOC 2 Report
• SOC 3 Report
• Penetration test report
• HIPAA Report

[IMAGE PLACEHOLDER 5: Railway Trust Center: compliance badges]

Railway describes the following controls for its own systems in the Trust Center’s Data Security section. Confirm their scope for your workload rather than treating the provider’s internal controls as application configuration guarantees.

Railway’s compliance documentation identifies SSO as an enterprise capability. Its Trust Center describes SSO, MFA, and role-based access controls; confirm the supported enforcement options and customer scope during your review.

Railway’s Trust Center Network Security section describes:

• Firewalls to monitor and control network traffic
• Protection against IP and DNS spoofing
• Traffic filtering to block malicious packets

Railway’s App Security disclosures describe vulnerability scans and patch management, peer review and static/dynamic code analysis, secure development training, a bug bounty program, bot detection, and a WAF protecting its web applications. These are provider security practices; your application still needs its own security controls.

Railway’s Trust Center describes internal audit logging across support, web applications, technical operations, and staging and production management infrastructure. Review customer-visible event coverage and retention separately; internal provider logs do not establish which application or database events your team can export.

For the environment separation and least-privilege requirements discussed earlier, review your proposed access policy with Railway and request supporting evidence through the Trust Center. Confirm who can deploy, read production logs, view secrets, and change permissions before relying on a role name as an access boundary.

Railway’s compliance documentation directs teams with BAA and compliance needs to its solutions team. Confirm the support response times and contractual SLA applicable to your agreement.

Review compliance documentation at trust.railway.com. For HIPAA BAAs, enterprise agreements, or compliance questions, use the contact details in Railway’s compliance documentation.

Compliance on managed infrastructure is achievable when you understand the shared responsibility model and verify that your provider's controls align with your framework requirements. The questions in this guide provide a checklist for evaluating providers and structuring your own implementation work.

No; Railway's report supplies evidence about the provider. Your organization's controls and examination scope still need their own evaluation, consistent with AICPA's description of SOC assurance.

No; a BAA establishes required contractual obligations with a business associate. You also need the applicable safeguards and risk analysis described in HHS's cloud guidance.

No; region selection addresses only part of the processing arrangement. Review your data flows and any transfers outside the EEA using the EDPB's transfer guidance.

Yes, qualifying provider-hosted iframe integrations can be eligible for SAQ A, as PCI SSC explains. Confirm all applicable eligibility criteria, including the script-security criterion for embedded payment forms, and the assessment accepted for your business.

No; ISO 27001 uses an information security management and risk treatment approach. Your risk assessment and contractual requirements should determine the appropriate tenancy.

Plan for your team to maintain its application dependencies and custom container images. Confirm the provider's maintenance scope and record the allocation of responsibilities, following HHS's guidance on cloud security responsibilities.

Start with Railway's Trust Center for security reports and supporting documentation. Its compliance documentation explains the BAA process and DPA access.