DEV Community: Chethna

CSA STAR and the Cloud Controls Matrix: A Security Engineering Perspective

Chethna — Wed, 14 Oct 2026 09:43:08 +0000

Cloud security teams manage a wide range of technical and organizational risks. Identity systems, storage services, APIs, network boundaries, logging platforms, and third-party integrations all influence the security of a cloud service.

CSA STAR provides a framework for communicating how cloud providers address security expectations through structured assessment and assurance approaches.

What Is the Cloud Controls Matrix?

The Cloud Controls Matrix (CCM), developed by the Cloud Security Alliance, organizes cloud security controls into domains relevant to cloud computing.

These domains cover areas such as:

Identity and access management.

Data security and privacy.

Governance and risk management.

Security monitoring and incident response.

Infrastructure and application security.

Business continuity and resilience.

The matrix provides a structured way to examine cloud security practices. The precise criteria used depend on the applicable version and CSA STAR assessment route.

Where CSA STAR Fits Into Security Engineering

Engineering teams can use cloud security criteria to examine whether security responsibilities are defined and consistently addressed across systems.

For example, identity controls should account for user authentication, privileged access, service accounts, and access revocation. Logging practices should provide appropriate visibility into security-relevant events. Data protection measures should reflect how information is stored, transmitted, and accessed.

These practices are not exclusive to CSA STAR, but they are relevant to the broader assessment of cloud security maturity.

CSA STAR and ISO/IEC 27001

ISO/IEC 27001 specifies requirements for an Information Security Management System. CSA STAR adds cloud-specific criteria and assurance mechanisms.

Where a CSA STAR route incorporates ISO/IEC 27001, the provider must meet the requirements associated with the applicable route and scope. Organizations should not assume that an existing ISMS certificate automatically establishes CSA STAR status.

Selecting an Assurance Route

CSA STAR includes self-assessment and independent assurance options. Cloud providers should verify the applicable program criteria, evidence requirements, scope, and assessment process before making certification claims.

For a broader overview of the program and its relevance to cloud service providers, see this CSA STAR certification resource.

For engineering teams, the central objective is to connect technical controls with clearly defined responsibilities and evidence that accurately represents the cloud services being assessed.

DPDP Act Compliance: A Technical View of Personal Data Governance

Chethna — Wed, 14 Oct 2026 09:27:40 +0000

India's Digital Personal Data Protection Act, 2023, creates important considerations for security engineers, developers, privacy teams, and organizations processing digital personal data.

From application databases to analytics platforms and third-party APIs, personal data can move through multiple systems. Understanding these flows is important when translating statutory obligations into operational controls.

Identify Personal Data and Processing Activities

Start by identifying where digital personal data enters the environment and how it is used.

Common sources include registration forms, customer databases, HR platforms, mobile applications, payment-related systems, analytics tools, and cloud-based services.

A useful inventory records the purpose of each processing activity, the categories of personal data involved, relevant recipients, retention considerations, and the systems through which the data passes.

Build Consent and Notice Into Application Workflows

Where consent is required, applications should capture and manage it in accordance with the DPDP Act.

Engineering considerations include recording the applicable consent, maintaining the notice presented to the individual, enabling consent withdrawal, and propagating relevant changes across connected systems.

Consent should not be treated as a universal legal basis. The Act also recognizes specified legitimate uses, subject to their applicable conditions.

Apply Appropriate Security Safeguards

Technical safeguards should reflect the systems involved and the risks to personal data.

Relevant measures may include:

Role-based access control and least-privilege permissions.

Encryption for data in transit and, where appropriate, at rest.

Centralized logging and security monitoring.

Secure development and configuration practices.

Vulnerability management and timely remediation.

Tested incident response and breach escalation procedures.

Appropriate controls for third-party access.

These measures contribute to security, but organizations must evaluate the full set of obligations applicable to their circumstances.

Design for Retention and Erasure

Personal data should not remain in production databases, analytics environments, backups, and connected services indefinitely without a valid reason.

Engineering teams should establish retention rules and define how deletion requests are handled across relevant systems. Backup cycles, legal retention obligations, and downstream data recipients also need consideration.

The applicable statutory requirements determine when erasure is required and what exceptions may apply.

Establish a Personal Data Breach Process

Organizations should define how suspected incidents are detected, escalated, investigated, and communicated. The DPDP Act includes obligations relating to notification of personal data breaches; organizations must determine the applicable requirements and timelines under the provisions in force.

Connect Technical Controls to Governance

A secure application does not, by itself, establish legal compliance. Organizations also need clear responsibilities, appropriate notices, processes for Data Principal rights, and oversight of personal data processing.

For an overview of the legal framework and its business implications, see this DPDP Act compliance resource.

The practical objective is to connect application-level safeguards with an organization-wide understanding of privacy obligations.

NIST 800-53 vs. 800-171: Scope, CUI, and Security Controls

Chethna — Wed, 14 Oct 2026 08:59:41 +0000

For security engineers and compliance professionals working in government-related environments, NIST SP 800-53 and NIST SP 800-171 are closely connected but serve different purposes.

Confusing the two can lead to incorrect assumptions about control coverage, system boundaries, and contractual obligations.

NIST SP 800-53: The Broader Control Catalog

NIST SP 800-53 provides security and privacy controls primarily used by federal agencies to protect information systems and organizational operations.

Its control families include:

Access Control (AC)

Audit and Accountability (AU)

Configuration Management (CM)

Identification and Authentication (IA)

Incident Response (IR)

Risk Assessment (RA)

System and Communications Protection (SC)

System and Information Integrity (SI)

Supply Chain Risk Management (SR)

The publication contains a broad catalog of controls that can be tailored to applicable requirements and system risk. Its role in federal cybersecurity is particularly relevant to FISMA-related security programs and FedRAMP authorization.

NIST SP 800-171: CUI Protection in Non-Federal Environments

NIST SP 800-171 focuses on Controlled Unclassified Information (CUI) handled by non-federal organizations.

Its requirements address practical security concerns such as access enforcement, multifactor authentication, audit logging, secure configurations, incident response, encryption, and system monitoring.

The publication is especially relevant to defense contractors and subcontractors whose agreements require protection of CUI. It is also central to CMMC Level 2, subject to the applicable program requirements and revision.

How the Publications Relate

NIST SP 800-171 draws from NIST SP 800-53, but it does not simply require every control in the larger catalog. Instead, it defines a more focused set of requirements for protecting CUI in non-federal systems.

This difference matters when defining the assessment scope. Security teams must identify which systems process, store, or transmit CUI, determine how those systems connect to other environments, and verify the requirements established by the relevant contract.

The revision also matters. NIST SP 800-171 Revision 2 contains 110 requirements, whereas Revision 3 reorganizes and updates the requirements. Organizations should verify the revision referenced by their applicable obligations rather than assume the same requirement set applies in every case.

Which One Applies?

Federal information systems generally fall within the NIST SP 800-53 context. Non-federal environments handling CUI may fall under NIST SP 800-171 requirements. Some organizations encounter obligations related to both.

For a deeper comparison of applicability, control scope, and use cases, read the NIST 800-53 vs. NIST 800-171 article.

Understanding the relationship between the publications is a practical starting point for accurate control mapping and security planning.

PCI DSS 4.0 for Developers: Securing the Payment Data Lifecycle

Chethna — Tue, 13 Oct 2026 11:10:32 +0000

Payment security is not confined to the checkout page. It involves the systems, identities, networks, applications, and service providers that interact with the cardholder data environment.

For engineering teams, PCI DSS 4.0 provides a framework for understanding how technical decisions affect the protection of payment information.

The PCI DSS 4.0 requirements cover security objectives that apply across infrastructure, software, identity management, monitoring, and governance.

Map Payment Data Flows Before Changing the Architecture

Developers should understand where payment data enters an application, which components process it, whether any data is retained, and how it moves to payment processors or other services.

This information is important when defining the cardholder data environment and its assessment scope.

A payment integration that uses an external provider may change the systems that directly handle account data, but it does not automatically remove every PCI DSS responsibility. The integration model, connected systems, and provider relationship must be evaluated under the applicable requirements.

Secure Network Boundaries and System Configurations

PCI DSS requires appropriate network security controls and secure configurations for relevant system components.

From an engineering perspective, this includes examining unnecessary services, default credentials, network access paths, configuration changes, and the separation of systems where appropriate.

Network segmentation can reduce exposure and help define the scope of the cardholder data environment when designed and validated correctly.

Protect Stored and Transmitted Account Data

The first consideration should be whether account data needs to be stored. Retaining less data can reduce exposure, but any storage decision must comply with the applicable PCI DSS requirements.

Where storage is permitted, required protections must be applied. Sensitive authentication data has additional restrictions and generally must not be retained after authorization.

Data transmitted over open, public networks must also receive appropriate cryptographic protection. Developers should ensure that payment integrations use suitable security protocols and do not expose sensitive information through application logs, error messages, or debugging output.

Build Security Into Software Maintenance

Requirement 6 addresses secure systems and software. Engineering teams should consider secure development practices, vulnerability management, timely security updates, and controlled changes.

Code review, dependency management, security testing, and change control can contribute to this objective, subject to the requirements applicable to the environment.

A secure release process should also account for the way changes may affect payment data flows, system configurations, and security boundaries.

Apply Least Privilege and Strong Authentication

Access to systems containing or affecting payment information should be limited according to business need.

Unique identities, appropriate authentication, controlled administrative privileges, and multi-factor authentication where required help reduce unauthorized access risks.

Access should also be reviewed when employees change roles or leave the organization.

Monitor and Test the Environment

PCI DSS includes requirements for logging and monitoring system activity, alongside regular security testing.

Engineering teams should understand which events must be recorded, how relevant logs are protected, and how suspicious activity is identified. Vulnerability scanning and penetration testing may also be required according to the applicable requirements and environment.

Testing should evaluate whether security controls remain effective as systems evolve.

Treat PCI DSS as a Continuing Engineering Responsibility

PCI DSS 4.0 is not simply a final security checklist before a release. Its requirements affect architecture, development, operations, identity management, and the ongoing maintenance of payment environments.

Teams that understand their payment data flows and applicable security obligations are better positioned to make informed technical decisions, maintain appropriate controls, and protect cardholder information throughout the payment lifecycle.

CMMC 2.0 for Defense Contractors: Understanding the Security Boundaries

Chethna — Tue, 13 Oct 2026 10:10:49 +0000

For organizations working in the U.S. defense supply chain, CMMC 2.0 raises a practical technical question: which systems, users, and services are subject to the applicable cybersecurity requirements?

The answer begins with the contract and the information being handled.

Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) have different protection requirements. CMMC 2.0 uses three levels to align cybersecurity expectations with the sensitivity of that information.

The CMMC certification framework outlines the model that defense contractors need to understand when determining their applicable obligations.

Level 1: Fundamental Safeguards for FCI

Level 1 focuses on basic safeguarding practices associated with FAR 52.204-21. The requirements cover areas such as authorized access, authentication, physical security, system maintenance, and information protection.

From a technical perspective, organizations need to understand which users can access relevant information, how access is controlled, and whether systems are maintained in a way that reflects the required safeguards.

Applicable Level 1 organizations generally perform annual self-assessments and provide the required compliance affirmations.

Level 2: CUI and the NIST SP 800-171 Requirements

Level 2 aligns with NIST SP 800-171 and addresses organizations handling CUI when their contracts require this level.

The technical implications extend across several connected areas:

Identity and access management: Organizations need appropriate restrictions on who can access systems and information, including administrative privileges.

Configuration management: System configurations and changes need appropriate control to reduce the risk of unauthorized or insecure changes.

Audit and accountability: Relevant system activity must be addressed through the applicable logging, monitoring, and accountability requirements.

Incident response: Organizations need defined arrangements for handling and reporting security incidents in accordance with applicable obligations.

System integrity: Security measures must address threats such as malicious code, vulnerabilities, and unauthorized changes.

Depending on the contractual requirements, Level 2 may require assessment by a Certified Third-Party Assessment Organization (C3PAO).

Level 3: Additional Protection Against Sophisticated Threats

Level 3 is intended for selected contractors supporting the DoD's most sensitive programs. It introduces additional security requirements derived from NIST SP 800-172.

The focus includes enhanced threat detection, monitoring, security architecture, incident response, and resilience against advanced adversaries.

The exact obligations depend on the applicable Level 3 requirements and assessment arrangements.

Why the System Boundary Matters

A security control cannot be evaluated accurately without understanding the systems and information to which it applies.

Consider a contractor that stores technical data in a cloud environment, accesses it through employee endpoints, and relies on external services for administration. The relevant security boundary may need to account for the data, users, endpoints, cloud services, and supporting infrastructure, depending on the applicable scoping rules.

Organizations should map information flows, identify relevant assets, and determine how connected services affect the assessment boundary.

This also helps stakeholders distinguish systems that process CUI from other business environments, while ensuring that required connections and dependencies are not overlooked.

Evidence and Ongoing Control Operation

CMMC assessments examine more than whether a policy exists. The applicable assessment process evaluates whether required practices are in place and supported by appropriate evidence.

Depending on the requirement, evidence may include system configurations, access records, security logs, training records, incident response procedures, and other relevant records.

Maintaining this evidence over time depends on clear ownership, consistent processes, and changes being reflected in the organization's security arrangements.

The Technical Takeaway

CMMC 2.0 is not simply a checklist of cybersecurity products. It connects information classification, system boundaries, security controls, evidence, and contractual requirements.

For technical teams, understanding these relationships is essential to determining which obligations apply and maintaining effective protection for government information across the defense supply chain.

ISO 45001 for Manufacturing and Construction: Treating Safety as a System

Chethna — Tue, 13 Oct 2026 09:51:04 +0000

In industrial environments, occupational health and safety is rarely a single-process problem.

A manufacturing plant might manage machinery, chemical storage, electrical maintenance, contractor access, and emergency response through different departments. A construction project may involve subcontractors, temporary structures, lifting equipment, excavation work, and constantly changing site conditions.

When these activities are managed independently, hazards can fall between responsibilities. ISO 45001 provides a management system framework for connecting risk identification, operational controls, leadership, worker participation, and performance evaluation.

Start With the Operational Context

Before evaluating individual controls, an organization needs to understand the activities and conditions that influence occupational health and safety.

For manufacturing facilities, this may include production processes, equipment maintenance, warehousing, hazardous substances, and workforce arrangements. Construction businesses must also consider project-specific hazards, temporary worksites, subcontractors, and changes in site conditions.

The scope of the occupational health and safety management system should reflect the organization's actual activities and relevant obligations.

Connect Hazard Identification With Operational Controls

A risk assessment has limited value if its findings do not influence work practices.

Consider a maintenance activity involving industrial machinery. The organization needs to identify relevant hazards, evaluate risks, establish appropriate controls, communicate responsibilities, and determine whether the controls remain effective.

A construction company faces a similar challenge when managing work at height. Equipment selection, inspection, worker competence, supervision, and emergency arrangements must work together rather than exist as isolated requirements.

Treat Worker Participation as an Operational Input

Workers often understand the practical limitations of workplace procedures. They may identify recurring near misses, unsafe equipment conditions, confusing instructions, or risks created by changes in workflow.

Clear reporting channels and meaningful consultation enable these observations to inform risk reviews and operational decisions.

ISO 45001 places particular emphasis on worker consultation and participation, making employee involvement an important element of the management system.

Measure More Than Incidents

Incident statistics reveal outcomes, but they do not provide a complete picture of preventive performance.

Organizations can also examine:

Near-miss reports and recurring hazard patterns

Workplace inspection results

Completion of role-specific training

Changes in risk assessments

Outstanding corrective actions

Emergency exercise findings

These indicators can reveal whether controls are being maintained and whether recurring problems require further attention.

Evaluate the Management System Against ISO 45001

Organizations pursuing certification need to understand the standard's requirements across leadership, planning, operational control, performance evaluation, and continual improvement.

The ISO 45001 certification requirements provide a reference point for understanding how conformity with the occupational health and safety management system standard is evaluated.

The Key Takeaway

A safety system should reflect how work actually happens. Policies and procedures matter, but their effectiveness depends on clear responsibilities, suitable controls, worker participation, and regular evaluation.

For African manufacturing and construction businesses, ISO 45001 provides a structured framework for connecting these elements and managing occupational risks consistently across facilities and projects.