S2000-023 Customer Workload Environment

Customer Workload Environment Detailed Explanation

1. Workload Classification

Workload classification is the foundation of designing a compliant architecture.
You cannot choose controls, resiliency levels, or architectural patterns until you know:

• What the workload does

• How important it is

• What kind of data it handles

• How regulators treat it

Think of classification as labeling the workload correctly, so you know how much protection it needs.

1.1 Regulatory criticality

Regulatory criticality answers the question:

“How important is this workload from a regulatory perspective?”

There are usually three categories:

1.1.1 Mission-critical vs non-critical

• Mission-critical workloads

  • These must never go down.

  • Examples:

    • Core banking systems

    • Payment gateways

    • ATM transaction processing

    • Trading systems

    • Real-time fraud detection

  • If they fail:

    • Customers cannot access money

    • Payments stop

    • Banks risk regulatory fines

    • Reputation damage is severe

• Non-critical workloads

  • Failure has lower impact

  • Examples:

    • Internal HR tools

    • Marketing applications

    • Non-production environments

Mission-critical workloads require:

• Higher availability

• Stronger controls

• More resilient design (e.g., multi-zone, multi-region)

• Better monitoring

• Faster recovery times

Non-critical workloads can use simpler designs.

1.1.2 Regulated vs partially regulated vs non-regulated

• Regulated workloads

  • Directly governed by financial regulations

  • Contain sensitive or regulated data

  • Require strict controls

  • Examples:

    • Payment services (PSD2, PCI DSS)

    • Customer account management

    • KYC (Know Your Customer) systems

• Partially regulated workloads

  • Still important

  • Some controls apply, but not as strict

  • Examples:

    • Internal reporting systems

    • Some analytics systems

• Non-regulated workloads

  • No regulatory requirements

  • Still need basic security, but not full financial controls

  • Examples:

    • Marketing websites

    • Test environments (with no customer data)

Correctly identifying these categories is crucial because:

• Regulated workloads must follow the IBM Cloud Framework for Financial Services more strictly

• Non-regulated workloads can use simpler cloud resources

1.2 Data sensitivity

Data is the most important asset in finance.
Classifying data properly ensures it is protected according to its sensitivity.

Typical categories:

1.2.1 Public

• No confidentiality requirements

• Examples:

  • Public website content

  • Marketing materials

1.2.2 Internal

• For internal employees only

• Not harmful if leaked, but still needs protection

• Examples:

  • Internal reports

  • Internal dashboards without customer data

1.2.3 Confidential

• Must be protected

• Disclosure causes business harm

• Examples:

  • Employee data

  • Financial policies

  • Internal strategies

1.2.4 Highly sensitive

This is extremely important in finance.

Examples:

• PII (Personally Identifiable Information)

  • Names

  • Addresses

  • ID numbers

  • Phone numbers

• Payment card data (PCI DSS)

• Bank account details

• Transaction history

• Risk models

• Trading strategies

Highly sensitive data requires:

• Strong encryption (at rest and in transit)

• Strict access control

• Detailed audit logging

• Proper key management

• Secure networking boundaries

• Compliance with data-protection laws

1.3 Business impact

Business impact answers:

“What happens to the business if this workload fails?”

Three dimensions:

1.3.1 Financial impact

Examples:

• Customer cannot transfer money

• Trading desk loses opportunities

• Bank faces penalties

• Payment network loses revenue

Higher financial impact → stronger resiliency requirements.

1.3.2 Reputational impact

Banks depend heavily on trust.
A failure that becomes public may:

• Harm customer confidence

• Attract regulatory attention

• Damage the brand

Examples:

• Online banking outage

• Public data breach

1.3.3 Customer impact

If customers cannot:

• Pay

• Trade

• Transfer money

• Access accounts

• Verify balances

the bank’s business stops.

These workloads need:

• Faster RTO/RPO

• Multi-zone or multi-region designs

• Higher SLA expectations

1.4 Why workload classification matters

Once a workload is classified, you can determine:

1.4.1 Required controls & control levels

A highly regulated workload needs:

• Stronger access controls

• More encryption

• More logging

• More oversight

A non-regulated workload may only need basic security.

1.4.2 Resiliency expectations (RTO/RPO)

• RTO (Recovery Time Objective)
  How quickly the system must be restored after failure.

• RPO (Recovery Point Objective)
  How much data loss (time interval) is acceptable.

Mission-critical workloads → RTO/RPO must be very low.

1.4.3 Architectural patterns

Depending on the classification, you choose:

• Multi-zone (high availability)

• Multi-region (disaster recovery)

• Active-active (zero downtime)

• Active-standby (common DR pattern)

• Single-zone (only for non-critical workloads)

This ensures the architecture matches:

• Risk level

• Regulatory demands

• Business expectations

2. Existing Environment and Integration

Understanding the customer's existing environment helps you design architecture that fits into what they already have, not in isolation.

2.1 Typical environments

2.1.1 On-premises data centers

Many financial institutions still rely on:

• Legacy core banking systems

• Mainframes (z/OS)

• Monolithic applications

• Big proprietary databases

These systems are usually:

• Stable but hard to modernize

• Highly critical

• Difficult to migrate without downtime

• Under strict regulatory governance

Cloud designs must consider:

• Integration with legacy systems

• Secure connectivity

• Gradual migration strategies

2.1.2 Private cloud / virtualized environments

Many banks already have private clouds.

Common platform: VMware.

They may have:

• vSphere clusters

• NSX networks

• vSAN storage

• Internal automation tools

This is often the “first step” before hybrid cloud.

IBM Cloud for Financial Services supports this through:

• VMware regulated workloads

• Satellite deployments

• Direct Link connectivity

2.1.3 Hybrid / multi-cloud

Many financial institutions use:

• On-prem for core systems

• IBM Cloud for regulated workloads

• Other clouds (AWS/Azure/GCP) for analytics or internal apps

A typical hybrid pattern:

• Mainframe + IBM Cloud + analytics on other cloud

A multi-cloud design requires:

• Unified identity

• Consistent logging

• Network routing between clouds

• Shared compliance evidence

IBM Cloud Satellite helps unify some aspects of this.

2.2 Integration considerations

2.2.1 Connectivity (VPN, Direct Link)

Secure connectivity must:

• Encrypt traffic

• Be reliable

• Handle high throughput

VPN is good for quick setup.
Direct Link is better for:

• Core banking

• Trading systems

• High-volume payment flows

2.2.2 Network segmentation & routing

Banks must separate:

• Public services

• Private internal workloads

• Admin networks

• Sensitive systems

This prevents:

• Lateral movement during attacks

• Unauthorized access

• Compliance violations

IBM Cloud VPC supports this with:

• Subnets

• ACLs

• Security groups

2.2.3 Identity federation

Banks typically have existing identity systems:

• Active Directory

• LDAP

• SAML providers

• OAuth/OpenID Connect

Identity federation allows:

• Single sign-on

• Unified policy enforcement

• Centralized identity lifecycle management

IBM Cloud IAM can integrate with corporate IdPs, ensuring:

• Better user governance

• Consistent authentication

2.2.4 Logging & monitoring integration

Banks already have SOC tools:

• SIEM (Security Information and Event Management)

• SOAR (Security Orchestration, Automation, Response)

• Log analytics

Cloud logs must integrate with these for:

• Threat detection

• Compliance monitoring

• Incident response

IBM Cloud provides:

• Activity Tracker

• Flow Logs

• Syslog integrations

• Audit logs

3. Data Residency and Sovereignty

Financial institutions face very strict data laws.

This section determines where data can live and what rules apply.

3.1 Data residency

Data residency refers to:

“In which country or region must the data physically reside?”

Examples:

• Some countries require banking data to remain within national borders.

• Some regulators require multiple copies within the same region.

If a workload must comply with data-residency rules, the architecture must:

• Choose an IBM Cloud region that satisfies the requirement

• Avoid cross-region data movement

• Use Satellite if data cannot leave on-prem

• Ensure logs and backups also comply

3.2 Data sovereignty

Data sovereignty refers to:

“Which country’s laws apply to the data?”

This is different from residency.

Example:

• Data stored in Country A

• But processed by a cloud service legally governed by Country B

Banks must ensure:

• Regulatory compliance

• Correct legal jurisdiction

• Correct vendor certifications

• No violations of privacy laws

3.3 How IBM Cloud for Financial Services helps

IBM provides:

3.3.1 Region selection aligned with regulatory expectations

Regions are designed with:

• Strong physical security

• High resiliency

• Compliance certifications

Banks can choose regions that match:

• GDPR

• Local banking rules

• National cloud requirements

3.3.2 Satellite for local data processing

IBM Cloud Satellite allows:

• Data to remain on-prem

• IBM Cloud services to run locally

• Compliance with strict residency requirements

Satellite is perfect when:

• Regulations prohibit cloud storage

• Latency must be extremely low

• A cloud-like experience is wanted without data movement

4. Customer Operating Model

The operating model describes how the customer's organization works day-to-day.

Understanding this allows you to design cloud solutions that fit their processes, not force new ones.

4.1 Areas to analyze

4.1.1 Change management / releases

Questions to ask:

• How often do they deploy changes?

• Do they use a formal CAB (Change Advisory Board)?

• Are changes automated or manual?

• Do regulations require approvals?

Workloads with strict change control may require:

• Controlled CI/CD pipelines

• Deployment windows

• Audit trails

4.1.2 Incident & problem management

Banks follow strict processes:

• ITIL-based incident management

• Defined severity levels

• Formal problem investigation

• Root-cause analysis

Cloud design must support:

• Strong observability

• Clear ownership

• Automated alerts

• Fast recovery options

4.1.3 Security operations (SOC, SIEM)

Topics include:

• Who monitors alerts?

• How quickly must incidents be detected?

• What SIEM tools are used?

• How do they correlate cloud logs with on-prem events?

Cloud logs must integrate seamlessly to prevent blind spots.

4.1.4 Compliance audits & evidence collection

Banks undergo regular:

• Internal audits

• External audits

• Regulatory reviews

• Third-party risk assessments

Cloud design must enable:

• Easy access to logs

• Automated reports

• Observability into controls

• Documentation of compliance

4.2 Why the operating model matters

4.2.1 Automation (IaC, CI/CD)

If customers already use automation:

• You align with their tools (Terraform, Ansible, Jenkins, etc.)

If they don’t:

• You design simpler workflows

• Or introduce automation gradually

4.2.2 Logging, monitoring, audit evidence

You must know:

• Where logs flow

• How they are stored

• How long they are retained

• How evidence is collected

• Who needs access

4.2.3 Shared responsibility model

Depending on the customer’s internal processes:

• Some controls belong to IBM

• Some belong to partners

• Some belong to the customer

Understanding their operating model helps you assign responsibilities correctly.

Customer Workload Environment (Additional Content)

1. Landing Zone Requirements for Regulated Workloads

A landing zone provides a governed, pre-configured foundation for regulated workloads. It ensures that deployments begin within a secure and compliant environment.

1.1 Standardized Security Baselines

Regulated workloads must be deployed into landing zones that apply predefined security baselines. These baselines cover identity, network restrictions, logging, and encryption, ensuring consistent compliance across environments.

1.2 Predefined Security and Compliance Configurations

Landing zones include ready-made configurations such as network isolation patterns, IAM structures, encryption defaults, and logging pipelines. These configurations enforce foundational security controls before workloads are deployed.

1.3 Compliance Inheritance and Customer Responsibility

Workloads inherit the landing zone’s compliance posture, but inheritance is not complete. Customers remain fully responsible for workload-specific controls such as application access policies, data classification, and encryption key management.

1.4 Risk of Deploying Outside the Landing Zone

Deploying regulated workloads outside the landing zone introduces compliance gaps. Such deployments lack the mandatory baselines and may violate regulatory expectations or internal governance standards.

2. Workload Placement Decisions

Workload placement involves selecting the correct region, architecture, or platform to satisfy regulatory and operational needs.

2.1 Regulatory, Residency, and Sovereignty Constraints

Placement must respect laws governing data residency, sovereignty, and regional restrictions. Some workloads can only reside within specific jurisdictions or controlled environments.

2.2 Latency and On-Prem Integration

Workloads requiring low latency or tight coupling with on-prem systems may need placement near existing infrastructure or through hybrid approaches such as Satellite.

2.3 Cost, Resilience, and Service Availability

Cost constraints, resilience objectives, and the availability of validated services all influence placement. Some services exist only in select regions, shaping placement decisions for regulated workloads.

2.4 Satellite for Special Cases

Workloads with strict sovereignty requirements or ultra-low-latency needs may require deployment through Satellite to maintain local processing while using IBM Cloud services.

3. Control Applicability by Workload Type

Control strength varies depending on workload classification and associated risks.

3.1 Enhanced Controls for Critical or Sensitive Workloads

Mission-critical or highly sensitive workloads require strong IAM enforcement, strict encryption, enhanced logging, and real-time monitoring. These controls reflect the potential impact of failure or compromise.

3.2 Simplified Controls for Less Regulated Workloads

Non-regulated or internal workloads may follow lighter control profiles, though they must still meet baseline security requirements.

3.3 Controls for Analytics Workloads

Analytics workloads often require masking or pseudonymizing data. They may also require egress restrictions to prevent unauthorized data export.

4. Multi-Tenant vs Single-Tenant Architecture Considerations

Architecture tenancy decisions influence isolation, compliance, and risk posture.

4.1 Single-Tenant Deployment for Maximum Isolation

Single-tenant environments provide dedicated compute and storage, supporting workloads with the highest sensitivity or regulatory expectations.

4.2 Multi-Tenant Deployment with Strong Logical Isolation

Multi-tenant environments are suitable when logical isolation is strong and validated controls maintain separation between tenants.

4.3 Tenancy Aligned with Data Classification

Tenancy decisions must match regulatory and data classification requirements. Sensitive workloads should not share the same trust boundary with low-sensitivity workloads.

4.4 Avoiding Mixed-Sensitivity Deployment

Workloads of different sensitivity levels must not share the same high-risk boundaries without clear and justified isolation controls.

5. Data Flow and System Boundary Identification

Accurate documentation of data movement is essential for regulated environments.

5.1 Accurate Modeling of Data Flows

Workloads must include documentation showing how data enters, leaves, and moves through the system. This includes application flows, user entry points, and integrations.

5.2 Defining System Boundaries and Trust Zones

Boundaries must identify ingress and egress points, trust zones, encryption boundaries, admin access paths, and integration points.

5.3 Determining Control Applicability

Controls depend on where data flows and what boundaries it crosses. Incorrect boundary definitions lead to incomplete control coverage and compliance failures.

5.4 Avoiding Boundary Misclassification

Improper boundary definitions can leave parts of the architecture unprotected or subject to the wrong control category.

6. Environment Tier Structure (Prod / Non-Prod / Shared Services)

Regulated workloads require strict separation of environment tiers.

6.1 Isolation Between Production and Non-Production

Production and non-production environments must be fully isolated to prevent accidental access or impact.

6.2 Restrictions on Production Data Movement

Production data must not be copied into non-production unless anonymized or masked to avoid unauthorized exposure.

6.3 Shared Services under Least-Privilege Access

Shared services must apply strict access controls to ensure they cannot bridge unintended access between environments.

6.4 Restriction of Sensitive Data in Non-Production

Non-production environments must not store regulated or sensitive data unless explicitly permitted under reviewed controls.

7. Workload Isolation Patterns

Isolation protects workloads across multiple architectural layers.

7.1 Network Isolation

Network boundaries can be enforced using VPCs, subnets, ACLs, and security groups. These mechanisms prevent unauthorized connectivity.

7.2 IAM Isolation

IAM boundaries use separated roles, accounts, namespaces, and access groups to isolate administrative and workload identities.

7.3 Resource Isolation

Resource-level isolation includes dedicated clusters, segregated storage, separately provisioned databases, or isolated OpenShift namespaces.

7.4 Matching Isolation with Sensitivity

Isolation measures must align with workload sensitivity. Higher sensitivity demands stronger or layered isolation.

8. Compliance Inheritance Model

Compliance inheritance describes how workloads gain compliance posture from the platform and services.

8.1 Inheriting Controls from Validated Services and Landing Zones

Workloads automatically inherit controls embedded into validated services, platform policies, and landing zones.

8.2 Customer Ownership of Workload-Specific Controls

Inheritance does not remove customer responsibility for controls applied at the application or data layer.

8.3 Required Customer Configuration

IAM permissions, encryption key choices, and application security decisions remain under customer implementation and must follow compliance standards.

8.4 Understanding Inheritance Boundaries

Correctly identifying which controls are inherited and which require customer action is essential for complete compliance coverage.

9. IAM Segmentation and Access Governance

IAM governs how administrators, workloads, and users interact with cloud resources.

9.1 Segregation Between Production and Non-Production

IAM structures must enforce hard separation of access across environment tiers, preventing cross-environment interference.

9.2 Least-Privilege and Break-Glass Controls

Administrative access must follow least privilege. Emergency access must follow controlled, temporary break-glass procedures.

9.3 Identity Federation and Policy Alignment

Federated identity must enforce consistent authentication requirements across on-prem and cloud environments.

9.4 Conditional Access and Context Restrictions

Context-based restrictions must limit access based on source networks, geographies, or service contexts.

10. Resilience Patterns Mapped to Workload Needs

Resilience requirements follow workload classification and business impact expectations.

10.1 Multi-Region and Active-Active for Mission-Critical Workloads

The most critical workloads require redundant regional architectures to ensure continuity during regional disruptions.

10.2 Multi-Zone Architectures for Customer-Facing Applications

Applications facing external customers often require multi-zone deployment for uninterrupted service during zone outages.

10.3 Single-Zone for Low-Impact Workloads

Internal or non-critical workloads may use single-zone architectures to reduce cost when risk impact is minimal.

10.4 Disaster Recovery and Testing Requirements

DR plans must include defined RTO and RPO, periodic testing, and documented evidence to satisfy regulatory expectations.