Skip to content
s1ns3nz0 | Known Unknowns
Go back

Security Design Review: AWS EKS SaaS (10) - Regulatory Overlays

3 min read

The CI/CD stage can gate repeatable technical properties, but it cannot decide every obligation created by customer data, user geography, contracts, or privacy law. Those obligations are tracked as overlays on the EKS SaaS security contract.

Table of contents

Open Table of contents

Regulatory overlays are not a replacement baseline

CIA impact
  How harmful would disclosure, alteration, or outage be?

Regulatory and contractual overlay
  What must the organization do because of the data, users, or commitments?

The provisional EKS profile is Moderate, so the NIST SP 800-53B Moderate baseline remains the security starting point. A PIPA/ISMS-P trigger, customer data-processing agreement, or deletion promise can add requirements without changing that baseline.

Declaring an overlay does not prove compliance. The plugin maps obligations to technical and organizational requirements and records gaps that require owner or legal review.

The EKS data boundary is wider than the application tables

Tenant contact information, user attributes, authentication configuration, product data, orders, tenant mappings, logs, backups, container artifacts, and deployment records may all be in scope.

The tenant-management table can connect a customer domain to a Cognito user pool and Kubernetes namespace. Logs or build artifacts may contain identifiers that are not present in the main DynamoDB records. Privacy review must therefore follow data through EKS, AWS services, CI/CD, backups, and support access.

Deletion is a control-plane workflow

A tenant deletion request cannot be reduced to deleting one DynamoDB table. The process may need to address product records, order tables, tenant mappings, Cognito pools, namespaces, ingress objects, logs, backups, and deployment metadata.

The requirement must define who can request deletion, how the request is authenticated, which systems are checked, which retention exceptions apply, and what evidence proves completion. A shared deletion workflow has platform-wide blast radius if it selects the wrong tenant or leaves data behind for many tenants.

PIPA/ISMS-P and customer commitments

For users in Korea, the plugin applies a PIPA/ISMS-P analysis overlay. It identifies areas such as personal-information governance, data-flow identification, access control, logging, incident response, retention, and deletion.

The mapping is not a certification opinion. It shows which obligations have a direct control relationship, which are only partially covered, and which remain organizational or legal work.

Customer contracts add a separate availability and processing layer. An SLA must connect to monitoring, incident handling, RTO/RPO evidence, and recovery tests. A data-processing agreement must connect to roles, instructions, support access, deletion, and notification responsibilities.

Region and transfer questions remain explicit

The analysis may declare storage in ap-northeast-2 and users in Korea and Japan, but that does not answer every transfer or residency question. CloudFront, Cognito, ECR, logs, backups, AWS support access, and external processors may introduce additional locations or access paths.

When the repository cannot establish whether a transfer is permitted or how long a copy is retained, the plugin records an unresolved applicability question rather than assuming the flow is acceptable.

Map obligations and retain gaps

direct mapping
  NIST or application requirement clearly addresses the obligation

partial mapping
  technical control exists, but process or legal work remains

unmapped obligation
  no bundled control expresses the obligation completely

For example, access enforcement can map to AC controls, while a privacy notice, data-subject request process, or contractual notification deadline may remain outside the technical catalog.

Output of the overlay stage

overlays:
  - id: pipa_isms_p
    status: applicable_candidate
    linked_requirements:
      - REQ-EKS-TENANT-CONTEXT-01
      - REQ-EKS-AUDIT-LIFECYCLE-01
      - REQ-EKS-TENANT-DELETION-01
    gaps:
      - deletion_evidence_across_backups
      - support_access_review
  - id: customer_data_processing
    status: declared
    owner: service-owner
    review_required: true

The result does not claim that the EKS SaaS sample satisfies PIPA, ISMS-P, or a customer contract. It records which obligations are in scope, which requirements support them, which evidence is missing, and which decisions need accountable review.

This completes the initial EKS SaaS review series. The technical security contract now connects service analysis, CIA impact, threats, blast radius, ownership, requirement authoring, lifecycle, evidence, CI/CD, and operating obligations.


Share this post:

Previous Post
Policy as Code Through the CI/CD Pipeline: What I Contributed to the SEAL Security Frameworks
Next Post
Security Design Review: AWS EKS SaaS (9) - CI/CD Verification