SC-04 System and Communications Protection - Information in Shared Resources

Last modified: May 22, 2026

Introduction

This document describes how Private Mendix Platform fulfills the SC-04 control.

Control ID SC-04
Control category SC - System and Communications Protection
Requirement baseline FEDRAMP MODERATE
Responsibility and ownership Mendix - Private Mendix Platform, Mendix - Studio Pro/Runtime, Mendix - Operator, Customer - Infra, Customer - Org

Control

The information system prevents unauthorized and unintended information transfer via shared system resources.

Supplemental Guidance

This control prevents information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (for example, registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection.

This control does not address:

  • Information remanence which refers to residual representation of data that has been nominally erased or removed.
  • Covert channels (including storage and/or timing channels) where shared resources are manipulated to violate information flow restrictions.
  • Components within information systems for which there are only single users/roles.

The following controls are related to this control:

  • AC-3
  • AC-4
  • MP-6

Responsibility

Shared Responsibility

This is a shared responsibility between Mendix and the customer.

Guidance

Mendix Responsibility

The Mendix Runtime and MX4PC (Operator) support separating app information to prevent unauthorized and unintended information transfer:

  • The Mendix Runtime supports separating application information into one or multiple separate databases as required.
  • Kubernetes pods are automatically separated by design, preventing information sharing between applications.
  • Each application instance has isolated memory space.
  • Database connections are scoped to individual applications.
  • Kubernetes namespaces provide logical isolation between applications.

Resource Isolation Mechanisms

  • Memory isolation: Each pod has isolated memory that is not shared with other pods.
  • Network isolation: Kubernetes network policies control communication between pods.
  • Process isolation: Processes in one pod cannot access resources of another pod.

Customer Responsibility

It is the customer's responsibility to:

  • Identify the appropriate level of information separation based on data sensitivity.
  • Define policies to prevent information transfer via shared resources.
  • Determine whether separate databases are required for different applications or data classifications.

Implementer Responsibilities

  • Infra Implementer: Separate information among databases for the Mendix App and MX4PC implementation as required by Customer policy.
  • App Implementer: Configure database separation and isolation as dictated by the Customer.
  • App Implementer: Ensure that applications do not share sensitive resources inappropriately.

Operator Responsibilities

  • Infra Operator: Ensure ongoing compliance with information separation policies.
  • App Operator: Verify that resource isolation is maintained during application updates.

Proof and Remarks

Resource isolation is achieved by deploying Private Mendix Platform and application environments in discrete pods, ensuring strict process and memory sandboxing between system components.

Private Mendix Platform pod:

Application pod:

Private Mendix Platform and hosted applications utilize distinct database instances with independent authentication, ensuring logical and administrative data separation.

Private Mendix Platform database:

Application database: