Financial Services · Managed platform (AWS)

Public Cloud Infrastructure

Your AWS environment, run by Moraph with guardrails written as code

Book a demonstration Request a technical briefing Factsheet

Overview

What you are buying

Moraph resells, sets up and runs Amazon Web Services environments for banks, credit unions, lenders and investment firms. We build a multi-account structure with preventive and detective guardrails written as policy as code, so storage holding consumer data cannot be made public, encryption and logging are required, and every exception is approved and recorded. AWS operates the cloud itself; Moraph operates your configuration of it; your organization keeps the decisions about risk, data and access.

The problem it solves

Financial institutions move workloads to AWS faster than their controls follow. Accounts are created by different teams with different settings, storage buckets are opened for a quick data transfer and never closed, and logging and encryption depend on whoever built the workload. Security teams find misconfigurations after the fact, and when examiners ask how the institution prevents consumer data from being exposed in the cloud, the answer is a mix of console screenshots, wiki pages and good intentions.

Accounts and workloads are configured by hand, so settings drift from the agreed baseline
A single storage bucket made public can expose consumer financial data
Guardrails exist on paper but are not enforced before a change reaches production
Evidence of cloud controls for examiners and auditors is assembled by hand

Who uses it

Banks, credit unions, lenders and investment firms running or moving workloads to AWS
CISOs and security teams who answer for cloud controls
Infrastructure and platform teams who want an operated landing zone rather than building one
Application teams who need cloud accounts quickly without bypassing controls
Internal audit, third-party risk and examiners reviewing cloud governance

Requirements it supports

Gramm-Leach-Bliley Act Safeguards (Interagency Guidelines Establishing Information Security Standards; FTC Safeguards Rule, 16 CFR Part 314)FFIEC Joint Statement on Security in a Cloud Computing Environment (2020)FFIEC IT Examination Handbook: Architecture, Infrastructure, and OperationsInteragency Guidance on Third-Party Relationships: Risk Management (2023)NYDFS Cybersecurity Regulation (23 NYCRR Part 500)SEC Regulation S-P (17 CFR Part 248), where applicable

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

Cloud security is shared: AWS runs the cloud, Moraph runs your configuration of it under the service agreement, and your organization owns its data, its risk decisions and its applications.

Area	Moraph	AWS	Your organization
Licensing and billing	Resells AWS usage and support under your agreement with Moraph, and reports spend by account and workload	Sets the terms of the AWS customer agreement and service pricing	Approves budgets and decides which workloads move to the cloud
Platform availability	Designs accounts and workloads to use the AWS availability features you choose, and tracks AWS service health for you	Operates regions, availability zones and AWS services under its own service commitments	Decides how much resilience each workload needs and accepts the cost
Landing zone and guardrails	Builds and maintains the account structure, service control policies, AWS Config rules and pipeline checks as version-controlled code	Provides the services that enforce them, such as AWS Organizations, AWS Config and IAM	Approves the baseline and every change to a guardrail
Identity and access	Configures federation from your identity provider, permission sets and break-glass procedures	Provides IAM and IAM Identity Center	Owns the identity provider, decides who gets which role, and certifies access
Monitoring	Watches CloudTrail, AWS Config, GuardDuty and Security Hub findings and triages them around the clock	Generates the logs and findings from its services	Receives escalations and decides on findings that affect business data
Incident response	Contains misconfigurations under agreed runbooks, escalates to you, and coordinates with AWS Support	Responds to incidents in the underlying cloud and its own services	Leads the incident, decides on customer and regulator notification, and owns forensic decisions
Changes	Raises, tests and applies infrastructure and policy changes through the pipeline after approval	Changes its own services, with notice under its own terms	Approves changes and exceptions under your change policy
Patching and updates	Keeps landing-zone code, agents and managed images current, and plans around AWS service changes	Patches the underlying infrastructure and managed services	Patches and maintains your own applications unless contracted separately
Data and encryption	Enforces encryption and key policies in code and reports any resource without them	Provides AWS KMS and storage encryption	Classifies data, decides where it may live and who holds keys
Evidence and audit	Produces control evidence, configuration history and the change record for each review period	Publishes its own compliance reports through AWS Artifact	Presents evidence to examiners and auditors and owns the findings

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of AWS Financial Services itself, which belongs to its vendor.

Step 1

Onboarding tracker

Moraph tracks each account from inventory to fully baselined, so you can see what is under control and what is still being brought in.

Account	Environment	Owner	Baseline findings	Status
example-lending-prod	Production	Lending platform team	0	Baselined
example-statements-prod	Production	Digital channels team	3 open	Remediating
example-analytics-dev	Non-production	Data team	5 open	Remediating
example-shared-network	Shared services	Infrastructure team	0	Baselined
example-sandbox-07	Sandbox	Innovation team	Not assessed	Inventoried

Step 2
Configuration baseline review
The baseline is reviewed with your security lead: what each guardrail does, where it applies and what it is set to.
Public Cloud Infrastructure · Baseline v14Sample data
Guardrail baseline · version 14 (proposed)
Scope
All production and non-production accounts
Allowed regions
Two US regions
S3 Block Public Access
Enforced at account level
Encryption at rest
Required, KMS keys
CloudTrail
Organization trail, cannot be disabled
Open exceptions
4
Changes from version 13
- Deny bucket policies granting access outside the organization
- Require encryption on new database snapshots
- Add detective rule for unencrypted file shares
Approve baselineReturn with comments
The baseline is reviewed with your security lead: what each guardrail does, where it applies and what it is set to.
Step 3
A blocked change
A change that would make a bucket public fails the pipeline check before it is deployed, and the reason is recorded.
Public Cloud Infrastructure · Change CR-2291Sample data
Change CR-2291 · example-statements-prod
1. Change submitted: new bucket for statement exportsApp engineer
2. !Policy check failed: bucket policy grants public readPipeline
3. Change revised to use pre-signed links for customersApp engineer
4. Policy checks passedPipeline
5. Production change approvedPlatform owner
6. Change applied and recordedMoraph engineer
A change that would make a bucket public fails the pipeline check before it is deployed, and the reason is recorded.
Step 4
Alert triage
When something gets through, a Moraph analyst triages the finding, corrects it under a runbook and escalates where your decision is needed.
Public Cloud Infrastructure · Finding F-80412Sample data
Finding F-80412 · example-analytics-dev
Source
AWS Config rule
Resource
example-analytics-export bucket
Issue
Bucket-level public access block turned off
Data classification tag
Customer data
Severity
High
Runbook
Re-enable public access block
Actions taken
- Public access block re-enabled under runbook
- No public access recorded in access logs for the period
- Escalated to security lead because the tag shows customer data
Escalate to security leadClose with action recorded
When something gets through, a Moraph analyst triages the finding, corrects it under a runbook and escalates where your decision is needed.
Step 5
Monthly service review
Each month Moraph brings the numbers and the open decisions to your platform owner and security lead.
Public Cloud Infrastructure · Service reviewSample data
Monthly service review · sample month
Changes applied
37
Changes blocked by policy checks
6
Findings opened / closed
52 / 49
Escalations to your team
3
Exceptions due for review
2
AWS service events affecting you
1
Decisions needed
- Renew or remove exception EX-114 on a legacy file share
- Approve baseline version 14
- Agree tagging rule for untagged spend
Record decisionsExport report
Each month Moraph brings the numbers and the open decisions to your platform owner and security lead.

Step 6

Access review

Your platform owner certifies who holds which roles in which accounts, with last use shown so unused access is easy to remove.

Person	Permission set	Accounts	Last used	Decision
Engineer 2041 (fictional)	Workload deployer	Lending accounts	Last week	Keep
Engineer 1187 (fictional)	Workload deployer	Statements accounts	Not used in 120 days	Remove
Analyst 3302 (fictional)	Read-only	All production	Yesterday	Keep
Moraph engineer group	Platform administrator	All	Time-bound sessions only	Keep
Contractor 0715 (fictional)	Workload deployer	Analytics dev	Contract ended	Remove

Workflows

The principal workflows

Onboard
Moraph sets up the AWS organization and landing zone for your institution, or takes over an existing one, and brings each account under the agreed baseline.
- Existing accounts, workloads and settings inventoried
- Target account structure and guardrail baseline agreed with your security lead
- Accounts enrolled and baseline applied through code, one group at a time
- Findings against the baseline listed and either fixed or recorded as exceptions
- Monitoring and escalation routes switched on and tested
Guard
Guardrails are written as code. Preventive policies stop risky actions such as making a storage bucket public; detective rules flag drift; pipeline checks stop non-compliant infrastructure before it is deployed.
- Infrastructure changes submitted as code to the pipeline
- Policy checks run against the change before deployment
- Non-compliant changes are rejected with the rule that failed
- Service control policies and S3 Block Public Access prevent the riskiest actions in every account
- AWS Config rules record any drift that gets through
Watch
Moraph's security operations team watches findings from AWS logging and detection services across all accounts and handles them under agreed runbooks.
- Findings from AWS Config, GuardDuty and Security Hub collected centrally
- Analyst triages each finding and links it to the account and owner
- Misconfigurations covered by a runbook are corrected and recorded
- Anything touching consumer data or needing a business decision is escalated to you
- Finding closed with the action taken and who decided
Review
Each month Moraph reviews the environment with you: drift, findings, changes, exceptions, access and spend, with evidence ready for audit.
- Monthly service report prepared from the environment and the change record
- Open exceptions reviewed for renewal or removal
- Access to accounts and roles certified by your platform owner
- Guardrail improvements proposed and scheduled
- Evidence pack exported for your audit or exam calendar

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Platform owner

Head of infrastructure, cloud platform lead, IT director

Owns the institution's AWS environment and decides what is built, what changes and who has access.

Sees

All accounts, workloads and their compliance with the baseline
Open change requests, exceptions and findings
Spend by account and workload
Monthly service reports and the change record

Does

Approves new accounts and changes to the landing zone
Approves changes to production infrastructure under your change policy
Certifies who has access to which accounts and roles
Reviews the monthly service report with Moraph
Sets tagging and cost allocation rules

Cannot

Approve a guardrail exception alone; the security lead approves it as well
Edit or delete entries in the audit trail or change record

Approvals: Approves accounts, production changes and access certifications; exceptions also need the security lead.
Notified about: Change requests waiting for approval, failed deployments, escalated findings and access reviews coming due.

Security lead

CISO, information security officer, cloud security lead

Owns the guardrail baseline and the institution's decisions about cloud risk.

Sees

The guardrail baseline and its version history
All findings, their triage and their outcome
The exception register with review dates
Incident records and escalations

Does

Approves the baseline and changes to guardrails
Approves, renews or removes exceptions
Decides on escalated findings involving consumer data
Leads incidents and decides on notification
Sets which AWS regions and services are allowed

Cannot

Apply guardrail changes directly; they go through the pipeline
Approve an exception they requested themselves

Approvals: Approves guardrail changes and exceptions; their own requests need a second approver your organization names.
Notified about: High-severity findings, escalations, exceptions near their review date and guardrail changes ready for approval.

Application engineer

DevOps engineer, application developer, site reliability engineer

Builds and runs the institution's workloads in AWS within the guardrails.

Sees

Their team's accounts and the resources in them
Pipeline results, including which policy checks failed and why
Findings raised on their team's resources

Does

Requests new accounts through account vending
Deploys infrastructure as code through the pipeline
Fixes resources flagged against the baseline
Requests exceptions with a reason and compensating control

Cannot

Change service control policies, logging or security tooling
Make storage public or disable encryption where guardrails prevent it
Deploy to production without the approvals your change policy requires

Approvals: Production changes are approved by the platform owner; exception requests by the platform owner and the security lead.
Notified about: Failed policy checks, findings on their resources and decisions on their requests.

Moraph cloud engineer

Moraph cloud engineer, platform engineer

Builds and maintains the landing zone, guardrail code and pipeline, and applies approved changes.

Sees

Landing-zone and guardrail code and its history
Account configuration and drift across the organization
Change requests and their approvals
AWS service health and announced service changes

Does

Writes and tests guardrail and infrastructure changes
Applies approved changes through the pipeline
Enrolls new accounts and applies the baseline
Corrects drift under agreed runbooks
Opens and works cases with AWS Support on your behalf

Cannot

Approve their own changes
Access workload data in your accounts unless you grant time-bound access for a specific task
Grant exceptions

Approvals: Every change they make is approved by your organization, and reviewed by a second Moraph engineer before it is applied.
Notified about: Approved changes ready to apply, failed deployments, drift findings and AWS service notices.

Moraph security operations analyst

Moraph security operations analyst, SOC analyst

Watches findings across every account and handles or escalates each one.

Sees

Findings from AWS Config, GuardDuty and Security Hub
Account owners, escalation contacts and runbooks
Earlier findings and how they were resolved

Does

Triages findings and sets severity
Applies runbook corrections such as re-enabling S3 Block Public Access
Escalates findings that need your decision
Records the action taken and closes findings

Cannot

Accept risk or close a finding as an exception
Change guardrails
Read the contents of your data stores

Approvals: Corrections outside an agreed runbook need approval from your security lead.
Notified about: New findings, by severity, and responses to escalations.

Moraph service manager

Moraph service delivery manager

Runs the service relationship: reporting, reviews, priorities and anything that is not working.

Sees

Service reports, open requests and escalations
Exceptions and their review dates
Spend and usage trends

Does

Prepares and leads the monthly service review
Tracks requests, changes and improvements to completion
Coordinates with AWS on account and support matters
Manages escalations about the service itself

Cannot

Approve changes or exceptions
Change configuration in your accounts

Approvals: None of their own; they bring decisions to your platform owner and security lead.
Notified about: Requests past their target, escalations and items due for the next review.

Auditor or examiner (read-only)

Internal auditor, external auditor, regulatory examiner (under temporary access)

Reviews cloud controls and evidence without being able to change anything.

Sees

The guardrail baseline and its history
Configuration compliance and drift for the period in scope
The change record, exception register and findings
Monthly service reports

Does

Reads and searches evidence within their scope
Exports evidence they have been given access to, with each export logged
Leaves review notes where your organization enables them

Cannot

Change, approve or close anything
See accounts or periods outside the scope granted
Keep access after it expires

Approvals: Their access is approved by the platform owner or security lead, with a scope and an end date.
Notified about: Nothing by default.

Permissions at a glance

Action	Platform owner	Security lead	App engineer	Moraph engineer	Moraph SecOps	Service mgr	Auditor
Request a new account	Full	Full	Own work only	No access	No access	No access	No access
Deploy infrastructure through the pipeline	No access	No access	Own work only	Full	No access	No access	No access
Approve production changes	Approves	No access	No access	No access	No access	No access	No access
Propose a guardrail change	Full	Full	No access	Full	Full	No access	No access
Approve a guardrail change	Approves	Approves	No access	No access	No access	No access	No access
Apply guardrail changes	No access	No access	No access	Full	No access	No access	No access
Request an exception	Full	Full	Own work only	No access	No access	No access	No access
Approve an exception	Approves	Approves	No access	No access	No access	No access	No access
Triage and correct findings	View only	View only	Own work only	Full	Full	View only	No access
Certify account access	Approves	View only	No access	No access	No access	View only	No access
View control evidence	View only	View only	Own work only	View only	View only	View only	View only
View audit trail	View only	View only	No access	View only	View only	View only	View only

Full
Own work only
Approves
View only
No access

How access is controlled

Nobody approves their own change or exception: Moraph engineers never approve the changes they write, and exceptions need both your platform owner and security lead.
Roles in AWS follow groups in your identity provider through IAM Identity Center, so joiners, movers and leavers are handled where you already manage them.
Moraph staff use named, time-bound roles for administrative work, and every action is recorded in CloudTrail in a logging account they cannot alter.
Roles and approval routes are agreed during onboarding and can be scoped by account, environment or business line. Auditors and examiners get temporary read-only access with a scope and an end date.

Features

What it does

Multi-account landing zone

Separate AWS accounts for production, non-production, logging, security and shared services, organized so policies apply by environment and business line.

Preventive guardrails

Service control policies stop actions your baseline forbids in every account, such as disabling CloudTrail, leaving approved regions or turning off S3 Block Public Access.

Public storage prevention

S3 Block Public Access is enforced at the account level, and bucket policies granting access outside your organization are rejected in the pipeline and flagged if they appear.

Pipeline policy checks

Infrastructure code is checked against your rules before deployment, so a change that would expose data or skip encryption fails with a clear reason.

Configuration drift detection

AWS Config rules record the configuration of every resource and flag changes that move away from the baseline.

Encryption by default

Storage, databases and backups must use encryption with keys managed in AWS KMS under key policies your organization approves.

Central logging

CloudTrail and service logs from every account flow to a separate logging account that workload teams cannot alter.

Threat detection triage

GuardDuty and Security Hub findings are triaged by Moraph analysts and handled under runbooks agreed with you.

Exception register

Every approved deviation from a guardrail is recorded with its reason, approver, compensating control and review date.

Account vending

New accounts are created from a request with the baseline already applied, so teams get an account without a manual security review of each setting.

Cost and usage reporting

Spend by account, workload and tag, with untagged resources and unusual changes in spend called out in the monthly review.

Control evidence

Configuration history, guardrail versions, findings and the change record exported for a chosen period, for internal audit and examiners.

Integrations

How it connects to your systems

Connects to	How	What flows
Your identity provider	Federation from your identity provider into AWS IAM Identity Center, so your password and multi-factor policies apply to every console and command-line session.	In: user identity and group membership for permission sets.
Infrastructure-as-code pipeline	Your source control and pipeline, or one Moraph provides, with policy checks run on each change before deployment.	In: infrastructure code. Out: check results and deployment records.
Your SIEM	CloudTrail, AWS Config and finding data forwarded to the security information and event management tool your security team already uses.	Out: logs and findings, by stream or scheduled export.
IT service management	Change requests, incidents and service requests raised in or synchronized with your ticketing system.	In and out: tickets, approvals and status.
AWS Support	Moraph opens and works support cases with AWS on your behalf under the support plan in your agreement.	Out: case details limited to what AWS needs to resolve the issue.
Moraph managed services	Findings and context shared with Moraph's Vulnerability Management, Privileged Access Management or Data Loss Prevention services where you use them.	Out: asset inventory and findings, as agreed.
Cost reporting	AWS cost and usage data summarized by account, workload and tag for your finance team.	Out: monthly cost reports and exports.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Your staff and Moraph's engineers sign in through identity providers with multi-factor authentication; your staff through yours.

Role-based access

Permission sets follow roles, so writing a change, approving it and applying it are separate.

Time-bound administrative access

Moraph staff can reach your data or keys only with explicit, time-bound authorization from you for a stated task.

Complete audit trail

Every console, command-line and pipeline action is logged with the person and time in a logging account that cannot be edited by workload or Moraph engineers.

Tested changes

Guardrail and landing-zone code passes Moraph's security testing gates before release, and a software bill of materials is kept for Moraph's tooling.

Region control

Workloads run only in the AWS regions you approve; Moraph operates environments from the United States, the United Kingdom or Australia to match.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Baseline compliance

For platform owner and security lead

Every account and resource type against the guardrail baseline, with non-compliant resources and how long they have been out of line.

Break down by: Account, Environment, Rule, Severity, Age
Delivered as: Live dashboard; CSV export
Used for: Seeing where the environment has drifted and who needs to act.

Open findings

For security lead and Moraph security operations

Findings from AWS detection services with their triage status, owner and action taken.

Break down by: Severity, Source service, Account, Status
Delivered as: Live dashboard; scheduled email
Used for: Making sure every finding is worked and escalations are answered.

Change record

For platform owner, change manager

Each change to infrastructure or guardrails with its request, test results, approvers and deployment outcome.

Break down by: Change type, Account, Approver, Outcome, Period
Delivered as: Live view; CSV export
Used for: Change management and post-incident review.

Public exposure check

For security lead

Storage buckets, snapshots and other resources with any access granted outside your organization, and the policy or exception that allows it.

Break down by: Resource type, Account, Exception status
Delivered as: Live view; scheduled email
Used for: Confirming that nothing holding consumer data is reachable from outside.

Management

Monthly service report

For platform owner, security lead, IT leadership

Changes, findings, incidents, exceptions, access reviews, AWS service events and spend for the month.

Break down by: Period, Account group, Category
Delivered as: PDF; reviewed in the monthly meeting
Used for: Governing the service and deciding priorities for the next period.

Spend by workload

For platform owner and finance

AWS spend by account, workload and tag, with untagged spend and notable changes from the previous period.

Break down by: Account, Workload tag, Service, Period
Delivered as: Live dashboard; CSV export
Used for: Allocating cost and catching unexpected growth.

Exception register

For security lead, risk committee

Every open exception with its reason, compensating control, approvers and review date.

Break down by: Rule, Account, Review date, Approver
Delivered as: Live view; PDF export
Used for: Keeping exceptions temporary and visible to risk governance.

Regulatory and audit

Control evidence pack

For internal audit and examiners

The guardrail baseline in force, configuration compliance history, the change record and findings for a chosen period.

Break down by: Control, Period, Account
Delivered as: On request; PDF and CSV export
Used for: Answering audit and exam requests for cloud control evidence.

Guardrail version history

For security lead and auditors

Each version of the policy-as-code baseline, what changed, who approved it and when it took effect.

Break down by: Policy, Change date, Approver
Delivered as: Live view; PDF export
Used for: Showing that guardrail changes were tested and approved.

Access

Access certification

For platform owner and security lead

Who holds which permission sets in which accounts, when each was last used, and the certification decision.

Break down by: Account, Permission set, User group, Last used
Delivered as: Live view; CSV export
Used for: Periodic access review and removing access nobody uses.

Privileged session log

For security lead and auditors

Every administrative and break-glass session, including Moraph staff sessions, with the authorization and actions taken.

Break down by: Person, Account, Authorization, Date range
Delivered as: Live view; CSV export
Used for: Evidencing that privileged access was authorized and used as intended.

Exports, access and evidence

Reports are built from AWS configuration, log and billing data in your organization, and from Moraph's change and service records.
Every report can be exported to CSV, and summary and evidence reports to PDF; the monthly service report is reviewed with you in a meeting.
Logs and findings can also be forwarded to your SIEM or data platform so your teams can build their own views.
Reports respect each viewer's role: application teams see their own accounts, while the platform owner, security lead and auditors see the whole environment within their scope.
Evidence reports can be run for a past period, and running or exporting a report is itself recorded.

Deployment

Where and how it runs

In your AWS organization

The environment is in AWS accounts owned by your institution, with Moraph operating them under the service agreement.

Under a Moraph reseller agreement

AWS usage is bought through Moraph and billed with the service, subject to AWS's terms.

Existing landing zone

Where you already have an AWS organization, Moraph takes over its operation and brings it under policy as code rather than rebuilding it.

With other Moraph services

Run alongside Moraph managed services for vulnerability management, privileged access or data loss prevention.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Discovery

We inventory your existing AWS accounts, workloads, identity setup and controls, and agree what the service covers. We need read access and a contact from your infrastructure and security teams.

Baseline design

Account structure, allowed regions and services, guardrails, logging and encryption standards are agreed with your security lead and written as code.

Landing zone build

The organization structure, logging and security accounts, identity federation and pipeline are built, or an existing landing zone is brought under the code.

Account migration

Existing accounts are enrolled in groups, findings against the baseline fixed or recorded as exceptions, and workload owners told what changes for them.

Monitoring and runbooks

Detection services are switched on, escalation routes agreed, and runbooks for common findings approved by your security lead.

Handover to run

Your teams are trained on requesting accounts, deploying through the pipeline and asking for exceptions, and the monthly review cycle begins.

Limitations

What it does not do

Worth knowing before you evaluate it.

Moraph is not AWS. AWS's own service commitments, support terms, roadmap and outages apply to the cloud itself, and Moraph cannot change them.
AWS usage and support bought through Moraph remain subject to AWS's customer terms and pricing.
Guardrails reduce the chance of misconfiguration; they do not remove it. Some risky configurations can only be detected after the fact rather than prevented.
Moraph operates the landing zone and guardrails. Building, patching and supporting your applications is not included unless contracted separately.
Decisions about data classification, risk acceptance, exceptions and incident notification remain with your organization.
The service covers AWS. Other clouds and on-premises infrastructure are outside its scope.
Moraph maps controls to frameworks your institution reports against and supports your own assessments; it does not certify your environment.
Workloads that cannot be deployed as code need a documented exception and are checked by detective rules only.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

Ask for the proposed guardrail baseline and check it against your information security policy
Try to deploy a public storage bucket in a test account and see where it is stopped
Review how an exception is requested, approved, recorded and reviewed
Walk through a sample finding from detection to escalation and closure
Check how Moraph staff access is authorized, limited in time and logged
Review the responsibilities table with your third-party risk team

Questions

Frequently asked questions

Who owns the AWS accounts and data?

Your institution does. The accounts sit in your AWS organization, and how operation is handed back at the end of the agreement is set out in the contract.

Can you take over an existing AWS environment?

Yes. We inventory what you have, agree a baseline, and bring existing accounts under it in groups rather than rebuilding them.

Does Moraph have access to our data?

Moraph engineers manage configuration, not your data. Access to data or keys needs your explicit, time-bound authorization for a stated task, and is logged.

What happens when AWS has an outage?

AWS's own service commitments apply. Moraph tracks AWS service health, tells you what is affected, works with AWS Support and helps with the recovery steps your design allows.

How is it priced?

AWS usage is billed under AWS's terms, through Moraph where you buy it from us, and the managed service is priced by the size and number of environments operated. See Working with Moraph for what drives a quotation.

Which policy-as-code tools do you use?

AWS-native controls such as service control policies and AWS Config rules, plus pipeline checks in the infrastructure-as-code tools agreed during onboarding, kept in version control you can read.

Next steps

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Public Cloud Infrastructure guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Public Cloud Infrastructure support guide.

Public Cloud Infrastructure

What you are buying

The problem it solves

Who uses it

Requirements it supports

Who is responsible for what

A short walkthrough

Onboarding tracker

Configuration baseline review

A blocked change

Alert triage

Monthly service review

Access review

The principal workflows

Onboard

Guard

Watch

Review

Who does what in the product

Platform owner

Sees

Does

Cannot

Security lead

Sees

Does

Cannot

Application engineer

Sees

Does

Cannot

Moraph cloud engineer

Sees

Does

Cannot

Moraph security operations analyst

Sees

Does

Cannot

Moraph service manager

Sees

Does

Cannot

Auditor or examiner (read-only)

Sees

Does

Cannot

Permissions at a glance

How access is controlled

What it does

Multi-account landing zone

Preventive guardrails

Public storage prevention

Pipeline policy checks

Configuration drift detection

Encryption by default

Central logging

Threat detection triage

Exception register

Account vending

Cost and usage reporting

Control evidence

How it connects to your systems

How your data is protected

Single sign-on

Role-based access

Time-bound administrative access

Complete audit trail

Tested changes

Region control

What you can report on

Operational

Baseline compliance

Open findings

Change record

Public exposure check

Management

Monthly service report

Spend by workload

Exception register