DEV Community: Chethna

DORA Third-Party Cloud Risk Management: A Technical Guide for Financial Institutions

Chethna — Thu, 05 Nov 2026 10:53:26 +0000

Cloud infrastructure is now deeply integrated into financial technology environments.

Banks, payment institutions, insurance companies, and investment firms use cloud platforms for application hosting, databases, transaction processing, data storage, monitoring, and infrastructure services.

From an engineering perspective, this creates distributed technology dependencies.

A financial application may rely on a cloud hosting provider, an identity service, an external database platform, and several subcontracted technology components. A failure affecting one dependency could influence multiple services.

DORA addresses these challenges through its ICT risk management and third-party risk management requirements.

1. Understanding DORA's ICT Third-Party Risk Framework

The Digital Operational Resilience Act has applied since 17 January 2025.

Article 28 requires financial entities to manage ICT third-party risks as part of their overall ICT risk management framework.

An important distinction is that outsourcing does not transfer regulatory responsibility.

Even when a cloud provider manages infrastructure, the financial entity remains responsible for ensuring that its DORA obligations are addressed.

2. Map Cloud Dependencies

Before evaluating cloud risks, organizations need a clear understanding of their technology dependencies.

A typical cloud-dependent financial service may involve:

Application hosting infrastructure.
Database and storage services.
Authentication and identity platforms.
API gateways and integrations.
Monitoring and logging services.
Backup and disaster recovery services.
External security and support providers.

Dependency mapping helps identify which services support critical or important functions.

It also helps organizations understand whether several business applications rely on the same underlying provider.

3. Assess Service Criticality

Not every cloud service creates the same operational risk.

A cloud application supporting an internal administrative activity may have a different risk profile from infrastructure supporting payment processing or customer access.

Financial entities should evaluate:

Business impact if the service becomes unavailable.
Information sensitivity.
Recovery requirements.
Availability expectations.
Provider substitutability.
Dependencies on other technology services.

This helps determine the level of monitoring and contractual protection required.

4. Understand the Register of Information

DORA requires financial entities to maintain a Register of Information covering contractual arrangements with ICT third-party service providers.

For technology and risk teams, maintaining this register requires reliable information about providers, services, contractual relationships, and relevant dependencies.

The information should remain accurate when services, providers, or contracts change.

This creates an important connection between procurement, legal, security, architecture, and ICT risk management teams.

5. Evaluate Cloud Contracts Under Article 30

DORA Article 30 establishes contractual requirements for ICT services.

For services supporting critical or important functions, agreements should address matters including:

Service descriptions and service levels.
Security and availability obligations.
Data processing and storage locations.
Subcontracting arrangements.
Access and audit rights.
Cooperation with competent authorities.
Business continuity arrangements.
Termination and transition requirements.

Engineering teams should be able to connect these contractual requirements with the actual technical architecture and provider capabilities.

For example, contractual data-location commitments should be understood alongside the cloud service's deployment and processing arrangements.

6. Manage Subcontracting and Supply Chain Dependencies

Cloud platforms are rarely built around one organization alone.

Providers may depend on infrastructure partners, software vendors, data centres, network operators, and specialist service providers.

These relationships can introduce additional risks.

Financial institutions should evaluate relevant subcontracting arrangements, particularly when services support critical or important functions.

The European Commission's Delegated Regulation (EU) 2025/532 provides additional requirements concerning the assessment of subcontracting arrangements for such services.

7. Monitor Provider Concentration Risk

A common architecture decision is to consolidate services within a single cloud ecosystem.

Although this may simplify management, it can increase dependency on one provider.

Organizations should identify:

Shared infrastructure dependencies.
Services relying on the same provider.
Potential single points of failure.
Migration constraints.
Alternative service options.

Multi-cloud architecture is not automatically a solution. It can introduce additional complexity, security challenges, and integration costs. The organization's actual risk assessment should guide the decision.

8. Design Practical Exit Strategies

A cloud exit strategy needs technical detail.

Organizations should consider:

Data export capabilities.
Application portability.
Infrastructure configuration dependencies.
Database compatibility.
API and integration changes.
Identity and access migration.
Backup restoration.
Migration testing.
Business continuity during transition.

A provider exit plan should be evaluated against realistic recovery and operational requirements.

9. Connect Engineering With Governance

DORA compliance is not only a legal or procurement responsibility.

Engineering teams understand the technical dependencies. Security teams evaluate vulnerabilities and controls. Procurement manages provider relationships. Legal teams review contractual arrangements. Senior management maintains governance responsibilities.

These teams need to work together to ensure that technical reality, contractual commitments, and risk assessments remain aligned.

Conclusion

DORA third-party cloud risk management requires financial institutions to understand and continuously monitor their technology dependencies.

Dependency mapping, service criticality assessments, supplier oversight, contractual controls, concentration risk analysis, and practical exit strategies are important components of this process.

Securing Manufacturing Supply Chains With ISO 27001: A Practical Guide for African Exporters

Chethna — Thu, 05 Nov 2026 10:12:39 +0000

Manufacturing supply chains are no longer isolated business environments. They depend on ERP systems, cloud infrastructure, supplier portals, production applications, logistics platforms, remote access technologies, and digital communication channels.

For African manufacturers exporting products internationally, these systems support daily operations and the exchange of sensitive business information.

But what happens when a supplier account is compromised, a production application becomes unavailable, or confidential engineering documents are exposed?

These are not exclusively IT problems. They can affect manufacturing schedules, procurement, customer relationships, and international deliveries.

This is where ISO 27001 becomes relevant.

1. Understand the Information Assets in Your Supply Chain

Before implementing security controls, manufacturers need to understand what information they hold and how it moves throughout their operations.

Typical information assets include:

Product designs and engineering drawings.
Production schedules and manufacturing records.
Supplier contracts and procurement documents.
Customer specifications and purchase orders.
ERP and inventory management databases.
Logistics and shipment records.
Cloud-hosted business applications.
Employee and financial information.

Mapping these assets helps identify where sensitive information is stored, processed, transferred, and accessed.

2. Establish an Information Security Management System

ISO/IEC 27001:2022 specifies requirements for an Information Security Management System (ISMS).

An ISMS provides an organized approach to identifying information security risks, evaluating their potential impact, selecting controls, and monitoring their effectiveness.

For an export manufacturer, the ISMS scope should reflect the business processes and systems that are important to its operations.

It could cover engineering, production planning, procurement, logistics coordination, customer management, and supporting technology infrastructure.

The scope should be based on the organization's actual context rather than an arbitrary list of IT systems.

3. Address Supplier and ICT Supply Chain Risks

Manufacturers rarely operate independently. They depend on suppliers, technology vendors, cloud service providers, outsourced maintenance teams, and logistics partners.

ISO 27001:2022 includes specific supplier-related controls:

Control	Security focus
A.5.19	Information security in supplier relationships
A.5.20	Security requirements within supplier agreements
A.5.21	ICT supply chain information security
A.5.22	Supplier service monitoring and change management

These controls are particularly useful when external organizations access confidential information or provide technology that supports manufacturing operations.

For example, a cloud provider hosting production-related information creates a different dependency from a logistics provider that only receives shipment details.

Organizations should evaluate each relationship according to its actual information security risks.

4. Apply Access Management and Secure Information Sharing

Access permissions should reflect business responsibilities.

An engineering employee may require access to technical drawings, whereas a logistics employee may only need shipment information.

Third-party personnel should also receive limited access based on their contractual responsibilities.

Manufacturers should consider:

Role-based access control.
Multi-factor authentication.
Periodic access reviews.
Secure file-sharing methods.
Information classification.
Logging and monitoring.
Timely removal of unnecessary access.

These practices help reduce unauthorized access and improve accountability.

5. Integrate Security With Incident Management

A cybersecurity incident can affect multiple parts of an export operation.

For example, ransomware affecting an ERP environment may disrupt inventory information, order processing, and production coordination.

Organizations should establish documented processes for incident identification, reporting, escalation, investigation, and response.

Supplier-related incidents should also be considered because external service disruptions can influence internal business operations.

6. Consider Manufacturing OT and IT Environments

Manufacturing environments can contain both traditional IT systems and operational technology (OT).

These environments may include connected equipment, industrial control systems, production monitoring applications, and remote maintenance solutions.

ISO 27001 is an information security management standard, not a manufacturing-specific OT cybersecurity standard. However, its risk-based approach can be applied to relevant information security risks within manufacturing environments.

Organizations with substantial OT exposure may also consider additional sector-specific cybersecurity guidance.

7. Understand What ISO 27001 Certification Demonstrates

ISO 27001 certification involves an independent assessment of an organization's ISMS against the applicable requirements of the standard.

It demonstrates conformity within the defined certification scope, not immunity from cyberattacks.

For export manufacturers, certification can support customer assurance and supplier evaluation processes when international buyers assess information security arrangements.

Conclusion

Securing an export supply chain requires more than protecting servers and factory networks. It involves managing information security risks across suppliers, employees, business applications, logistics partners, and external technology services.

ISO 27001 provides a structured way to manage these responsibilities and continually improve information security practices.

ISO 27001 for Hybrid Development Teams: Practical Security Considerations for Indian IT Companies

Chethna — Sat, 31 Oct 2026 07:31:32 +0000

Hybrid software development environments introduce security challenges across endpoints, repositories, cloud infrastructure, CI/CD pipelines, customer environments, and third-party services.

A developer might access a source code repository from a home network, connect to a cloud console from an office, and collaborate with a customer team using a separate project environment. Each connection creates an opportunity for unauthorized access or information exposure if security responsibilities are not clearly defined.

For Indian IT service providers, ISO/IEC 27001 provides a risk-based framework for managing these activities through an Information Security Management System (ISMS).

This article looks at relevant ISO 27001 control areas and how they relate to everyday development operations.

1. Define the ISMS Scope Around Actual Development Workflows

Before selecting security controls, an organization needs to understand its activities and determine the scope of its ISMS.

For a software development company, the scope may include:

Developer workstations and managed endpoints
Source code repositories
Issue tracking and collaboration platforms
CI/CD infrastructure
Development and testing environments
Cloud infrastructure and administrative accounts
Customer applications and production environments
Third-party development and support services

The scope should reflect the organization's activities, information assets, risks, contractual commitments, and business objectives.

A useful starting point is to map how information moves between these systems and identify who can access each environment.

2. Apply Role-Based Access Management

Access control is one of the most important considerations in distributed development.

Developers should not automatically receive access to every customer repository, database, cloud account, or production environment.

Access should be based on job responsibilities and business requirements. Organizations should also review permissions when employees change roles, move between projects, or leave the company.

Privileged accounts require additional protection because they can provide extensive access to systems and information.

3. Protect Authentication and Development Accounts

Development platforms, cloud services, repositories, and administrative interfaces should have appropriate authentication controls.

Multi-factor authentication can provide an additional layer of protection for sensitive applications and privileged accounts.

Organizations should also avoid shared user accounts where individual accountability is required. Authentication events and relevant access activities should be logged according to operational and security requirements.

4. Manage Developer Endpoint Security

A developer's workstation can become a direct route to source code, customer information, credentials, and internal systems.

Appropriate endpoint controls may include:

Secure device configurations
Regular software and security updates
Encryption where appropriate
Malware protection
Screen locking
Device management
Procedures for lost or stolen devices

Organizations should also establish rules for personal devices where applicable and define which devices can access sensitive development environments.

5. Address Remote Working Under Annex A 6.7

ISO/IEC 27001:2022 Annex A 6.7 specifically addresses remote working.

The control focuses on protecting information accessed, processed, or stored outside organizational premises.

For hybrid development teams, this may involve secure network connections, remote access restrictions, endpoint configurations, authentication, and rules for handling confidential information.

Organizations should define expectations for public Wi-Fi, personal storage services, shared computers, removable media, screen visibility, and unauthorized software.

Production access from remote locations should be limited to authorized personnel and justified by business requirements.

6. Secure the Software Development Lifecycle

Security should be integrated into development activities rather than treated as a final pre-release activity.

ISO/IEC 27001:2022 includes controls covering:

Secure development lifecycle activities
Application security requirements
Secure system architecture and engineering principles
Secure coding
Security testing
Outsourced development

Source code repositories should use appropriate permissions and authentication. Changes should be traceable to authorized users, and development environments should be separated from production where the risk warrants it.

Security testing should be selected according to the software type, technology stack, architecture, threat environment, and business risk.

Annex A 8.30 specifically addresses information security requirements for outsourced development.

7. Manage Cloud and Supplier Dependencies

Hybrid development environments often depend on cloud providers, software vendors, monitoring platforms, contractors, and managed service providers.

Organizations should identify which third parties can access information or systems and establish suitable security requirements.

Supplier agreements may need to address confidentiality, access restrictions, data handling, incident notification, subcontracting, and other customer or organizational obligations.

8. Monitor Relevant Development Activities

Logging and monitoring provide visibility into important events across distributed systems.

Depending on risk, organizations may monitor:

Authentication events
Privileged account activity
Repository access and changes
Cloud platform activity
Administrative operations
Security events
Relevant deployment activities

The purpose is to establish appropriate visibility into systems and activities that matter to the organization's information security risks.

9. Maintain Evidence of Control Operation

An ISMS requires more than written security policies. Organizations should retain evidence demonstrating that applicable controls operate as intended.

Examples include:

Access review records
Repository permissions
Device management records
Security logs
Employee training records
Supplier agreements
Change records
Security testing documentation
Incident records

The evidence required depends on the selected controls and the organization's operating environment.

ISO 27001 Is Risk-Based, Not a Fixed Checklist

ISO/IEC 27001:2022 contains 93 Annex A controls across organizational, people, physical, and technological categories. Not every control applies in the same way to every company.

Organizations select applicable controls based on their risk assessment and document the results in the Statement of Applicability.

An Indian software development company may have different security priorities from a cloud infrastructure provider or BPO organization. The ISMS should reflect the actual information handled, services delivered, and contractual obligations.

For further information about ISO/IEC 27001 and information security certification, organizations can explore the framework and its role in establishing a systematic security management approach.

The practical objective is to make security part of the development workflow, ensuring that access, devices, repositories, cloud platforms, and customer environments remain appropriately protected across office and remote locations.

FedRAMP for Healthcare SaaS: Cloud Security Architecture and Authorization Considerations for VA and HHS

Chethna — Sat, 31 Oct 2026 06:58:12 +0000

Healthcare SaaS vendors entering the US federal market need to consider more than application functionality and infrastructure availability. When a cloud service processes federal information on behalf of an agency, FedRAMP scope and authorization requirements may become relevant.

For engineering, cloud security, and compliance teams, the first challenge is understanding the service boundary and the agency's intended use.

FedRAMP establishes a standardised approach for assessing and authorising cloud computing services used by federal agencies. This article examines the main considerations for healthcare SaaS vendors targeting the Department of Veterans Affairs (VA) and the Department of Health and Human Services (HHS).

1. Determine Whether the Service Falls Within FedRAMP Scope

FedRAMP applies to qualifying cloud services that create, collect, process, store, or maintain federal information on behalf of federal agencies, subject to programme scope rules and exclusions.

The assessment should focus on the specific cloud service offering rather than the vendor's entire business.

Important questions include:

What federal information will the service process?
Which systems and environments are included?
What is the authorization boundary?
Which external systems and services are integrated?
Where does information enter, move through, and leave the service?
How will the federal agency use the service?

A vendor may operate several SaaS products or environments, but the assessed scope of one offering should not be represented as covering unrelated services.

2. Understand the VA and HHS Use Cases

VA Notice 25-07, issued in March 2025, amended VA Directive 6500 to connect cloud computing products and services undergoing VA Authorization to Operate with applicable FedRAMP requirements.

HHS also has policies addressing FedRAMP-certified cloud platforms and approval for their use in relevant circumstances.

However, the required certification path and security conditions depend on the agency, information, system, contract, and intended federal use.

Engineering teams should therefore review the actual procurement requirements before defining a target architecture or certification strategy.

3. Define the Cloud Service Boundary

A clear authorization boundary helps establish which components and responsibilities belong to the cloud service offering.

For a healthcare SaaS platform, relevant components may include:

Application services and APIs
Databases and storage systems
Identity and access management services
Cloud infrastructure
Administrative interfaces
Monitoring and logging components
External integrations
Supporting operational services

The boundary should accurately reflect the service being assessed. Unclear boundaries can create gaps in security documentation and misunderstandings about which systems are covered.

4. Maintain Security Evidence

FedRAMP requirements depend on the applicable programme path, impact level, and current rules.

The vendor generally needs to establish the service offering and boundary, address applicable security requirements, provide security information and evidence, complete assessment and verification activities, and maintain security information over time.

The programme is transitioning from the traditional Rev5 model towards FedRAMP 20x. The 2026 Consolidated Rules establish Class A, Class B, and Class C certification classes.

Depending on the class, the certification information may include:

Certification Package Overview
Security Decision Record
Key Security Indicators
Secure configuration information
Ongoing certification data

The emphasis is increasingly on maintaining current security information rather than relying solely on static documentation.

5. Understand Certification Versus ATO

A common mistake is treating FedRAMP certification as equivalent to an agency Authorization to Operate.

Certification provides reusable security evidence for a defined cloud service offering.

The agency evaluates how the service will be used in its own information system and makes the relevant authorization decision. The resulting ATO applies to the agency system and its specific use of the service.

This distinction matters when a healthcare SaaS platform integrates with VA identity services, electronic health records, analytics platforms, or other federal systems.

6. Consider HIPAA Separately

FedRAMP and HIPAA address different requirements.

FedRAMP concerns federal cloud security and authorization. HIPAA establishes requirements applicable to covered entities, business associates, and protected health information within its scope.

A healthcare SaaS provider may need to address both depending on the information, customer relationship, and contract.

7. Plan for Continuous Security Activities

FedRAMP is not simply a one-time certification milestone.

Vendors need to maintain relevant security information, address vulnerabilities, support ongoing verification and validation, and evaluate changes affecting the service.

Changes to infrastructure, integrations, configurations, and the service boundary should be considered within the ongoing security management process.

Conclusion

Healthcare SaaS vendors targeting VA and HHS should understand FedRAMP scope, service boundaries, certification classes, agency authorisation, and ongoing security expectations before entering federal procurement.

A structured FedRAMP certification and cloud security assessment approach can help connect technical security work with the evidence and assessment activities expected in federal cloud environments.

Securing Open Banking APIs with ISO 27001: Key Controls for PSD3 Environments

Chethna — Sat, 31 Oct 2026 06:31:51 +0000

Open banking APIs allow financial institutions and authorised third-party providers to exchange account information, initiate payments, and deliver connected financial services.

From an engineering perspective, this creates an environment involving API gateways, authentication services, payment platforms, cloud infrastructure, databases, external applications, and multiple supplier connections.

The security challenge is not limited to protecting an endpoint. It involves managing identities, permissions, communication channels, software vulnerabilities, operational dependencies, and security events across the entire environment.

ISO/IEC 27001 can provide a structured information security management framework for addressing these risks.

1. Understanding the PSD3 Context

PSD3 is the proposed successor to PSD2 under the European Union's payment services reform. The proposed framework addresses payment security, operational risks, authentication, fraud prevention, and incident management.

Organisations should monitor the legislative process and distinguish proposed requirements from obligations already applicable to their activities.

For engineering and security teams, the practical requirement is to understand which payment services, APIs, systems, and data flows are relevant to their regulatory responsibilities.

2. Common Open Banking API Security Risks

Some common weaknesses in API environments include:

Broken authentication and inadequate identity verification
Broken object-level or function-level authorisation
Excessive permissions for applications and services
Exposed access tokens and credentials
Insecure transport configurations
Injection and input validation weaknesses
Inadequate rate limiting and traffic controls
Vulnerable third-party dependencies
Insufficient logging and monitoring
Misconfigured cloud and network resources

A single weakness can affect more than the application where it originates. Connected systems may share credentials, permissions, data, or infrastructure.

3. Applying ISO 27001 Controls

ISO/IEC 27001:2022 provides requirements for an Information Security Management System. Its Annex A controls can be considered when selecting safeguards for identified risks.

Identity and access management

Define access requirements for users, applications, services, and administrators. Review privileges regularly and protect authentication information throughout its lifecycle.

Cryptography

Use appropriate cryptographic protection for sensitive information in transit and, where applicable, at rest. Manage keys, certificates, and related information through controlled processes.

Network security

Use segmentation, restricted connectivity, secure architecture, and appropriate traffic controls to reduce unnecessary exposure between internal and external systems.

Secure development

Integrate security into the software development lifecycle. Use code reviews, security testing, vulnerability management, secure configuration, and controlled changes.

Logging and monitoring

Capture relevant authentication, access, administrative, and API activity. Protect logs against unauthorised modification and monitor for unusual behaviour.

Supplier security

Assess external providers according to their access, data exposure, operational importance, and security responsibilities.

Incident management

Define processes for detecting, investigating, responding to, and recovering from security incidents affecting APIs and connected payment services.

4. Mapping API Risks to the ISMS

A useful approach is to connect technical risks with organisational risk assessment and treatment processes.

For example:

API security risk	Relevant security focus
Stolen credentials	Identity and access management
Exposed financial data	Cryptography and access restrictions
Insecure API endpoints	Secure development and vulnerability management
Suspicious API traffic	Logging and monitoring
Compromised suppliers	Supplier relationship security
Payment service disruption	Incident management and business continuity

This is an illustrative mapping, not a universal compliance checklist. The actual control selection should reflect the organisation's risk assessment and ISMS scope.

5. Managing the Statement of Applicability

The Statement of Applicability records selected controls and explains their applicability. For organisations with extensive API environments, it can help connect identified risks, selected controls, and information security objectives.

It should reflect the actual environment rather than simply listing every possible control.

6. Certification and Regulatory Compliance

ISO 27001 certification demonstrates conformity of a defined ISMS scope with the standard. It does not automatically establish PSD3 compliance.

Organisations should separately identify applicable legal requirements and evaluate whether their security controls address those obligations.

A structured ISO 27001 information security management approach can help connect API security engineering with organisational risk management, governance, and continual improvement.

Industrial VAPT for SCADA: A Practical Security Testing Approach for OT Environments

Chethna — Sat, 31 Oct 2026 05:54:38 +0000

Industrial networks are becoming more connected to enterprise IT infrastructure, remote maintenance services, and external platforms. This improves visibility and operational efficiency, but it also changes the security assumptions around industrial control systems.

For security engineers working with manufacturing, mining, energy, utilities, and other industrial environments, testing OT infrastructure requires a different approach from testing conventional enterprise networks.

The main challenge is balancing vulnerability discovery with operational continuity.

1. Start With Asset Discovery

Before testing an industrial environment, understand what is connected and how the assets communicate.

Depending on the environment, the scope may include:

SCADA servers
PLCs and RTUs
HMIs
Engineering workstations
Industrial switches and gateways
Supporting databases and services
Remote access infrastructure

Asset discovery is especially important when network documentation is incomplete or systems have been introduced over several years.

An accurate inventory helps identify assets that may be exposed through unnecessary connections or undocumented communication paths.

2. Understand the OT and IT Boundary

One of the important areas to review is communication between corporate IT and industrial OT networks.

Look at network segmentation, permitted communication paths, firewall rules, remote administration, vendor connectivity, and access restrictions.

The objective is to determine whether each connection is necessary and appropriately controlled.

Insufficient segmentation can increase the possibility that a compromise in one environment creates additional exposure in another.

3. Separate Vulnerability Assessment From Penetration Testing

These activities are related but have different objectives.

A vulnerability assessment identifies known or observable weaknesses such as:

Outdated software and firmware
Exposed services
Weak authentication
Insecure configurations
Insufficient segmentation
Vulnerable communication services

Penetration testing validates selected weaknesses through controlled testing.

In an OT environment, validation must account for the possibility that certain activities could affect sensitive equipment or physical processes.

4. Review Remote Access and Authentication

Remote access is often necessary for industrial maintenance and troubleshooting. However, external connections require clear boundaries.

Security reviews should examine authentication, authorization, user privileges, monitoring, and restrictions on third-party connectivity.

Shared accounts and excessive privileges can make it harder to establish accountability and control access to sensitive assets.

5. Account for Legacy Technology

Industrial assets may remain in operation for many years. Unlike conventional IT endpoints, they may not support frequent patching or replacement.

Compatibility testing, vendor support, maintenance schedules, and downtime requirements can all affect remediation decisions.

Where immediate patching is not practical, organizations can consider segmentation, access restrictions, monitoring, compensating controls, or planned upgrades.

6. Establish Safe Testing Rules

An industrial VAPT engagement should have clearly documented rules of engagement.

These should cover:

Authorized systems and networks
Excluded assets
Permitted testing techniques
Approved testing windows
Communication procedures
Emergency contacts
Conditions that require testing to stop

Operational teams should participate in planning because they understand the behavior and sensitivity of industrial systems.

Where direct testing presents unacceptable risk, passive discovery, configuration reviews, controlled laboratory testing, or representative systems may be appropriate.

7. Prioritize Findings Using Operational Context

Technical severity alone is not enough to determine the priority of an industrial vulnerability.

A useful assessment considers the affected asset, its role in the process, network exposure, exploitability, existing safeguards, and potential operational impact.

A weakness on an isolated supporting system may require a different response from one affecting a highly important industrial asset.

Reports should clearly distinguish confirmed vulnerabilities, potential weaknesses, informational observations, and validated exploitation results.

8. Close the Loop With Remediation and Retesting

The assessment should produce actionable recommendations rather than simply a list of technical findings.

Corrective actions may include patching, configuration changes, stronger authentication, network segmentation, access restrictions, removal of unnecessary services, and compensating controls.

Retesting can help verify whether selected vulnerabilities have been addressed.

Industrial VAPT cannot promise zero vulnerabilities, but it can provide useful evidence for improving security posture and reducing exposure.

Final Thoughts

Industrial cybersecurity is an ongoing engineering responsibility. Asset inventories, network documentation, remote access reviews, change management, and regular security assessments all contribute to a stronger OT security program.

For additional information about structured security assessments, see these VAPT and cybersecurity resources.

ISO 27017 and ISO 27018 for Multi-Tenant SaaS: A Practical Engineering View

Chethna — Wed, 28 Oct 2026 12:24:03 +0000

Multi-tenant SaaS architecture creates an interesting security challenge: multiple customers can share an application and infrastructure, but each customer's information must remain appropriately isolated.

For Indian SaaS engineering teams, ISO/IEC 27017 and ISO/IEC 27018 provide useful perspectives on managing cloud security and protecting personal information in applicable public cloud processing environments.

1. Start With Tenant Isolation

Tenant isolation should be enforced throughout the application stack, not just at the user interface.

Depending on the architecture, controls may include:

Server-side authorization checks.
Tenant-aware database access.
Object-level access validation.
Storage permissions and access policies.
Encryption and appropriate key management.
Security logging and monitoring.
Automated tests for cross-tenant access.

A tenant identifier alone is not a security boundary. Applications must validate that every request is authorized for the relevant tenant and resource.

ISO 27017 provides cloud-specific security considerations that can help organizations assess these responsibilities within their broader control environment.

2. Include Privacy in Data Lifecycle Design

SaaS platforms may process names, email addresses, employee records, account information, and other personally identifiable information.

ISO 27018 focuses on applicable public cloud environments where a provider acts as a PII processor. Engineering teams should understand where such information enters the system, where it is stored, which services can access it, and how it is retained or deleted.

Deletion workflows should consider more than the primary production database. Depending on the architecture and applicable requirements, customer information may also exist in backups, logs, replicas, exports, and testing environments.

3. Map Cloud Responsibilities

SaaS providers often depend on an underlying cloud provider. Security responsibilities may be inherited, shared, or managed directly by the SaaS organization.

Create a responsibility matrix that identifies ownership for infrastructure configurations, identity controls, application security, monitoring, incident response, backups, and customer-facing security commitments.

Clear ownership reduces the risk of gaps caused by assumptions between teams or suppliers.

4. Integrate With an Existing ISMS

ISO/IEC 27001 provides the requirements for an Information Security Management System. Rather than building a completely separate cloud security program, organizations can map relevant ISO 27017 and ISO 27018 considerations into existing risk assessment, control management, supplier oversight, and incident processes.

This approach can reduce duplicated work while retaining the specific cloud security and privacy considerations relevant to the service.

5. Make Changes Reviewable

A change to a database schema, authorization layer, cloud configuration, or third-party integration may affect security assumptions.

Teams should connect architecture changes with risk reviews, code reviews, testing, deployment records, and updated documentation where needed. Automated tests can help detect cross-tenant access problems before release.

6. Maintain Evidence That Reflects Reality

Useful evidence may include architecture diagrams, access reviews, security test results, supplier records, incident procedures, data lifecycle documentation, and control review records.

Evidence should describe the actual production environment, not an outdated design or a process that exists only on paper.

Engineering takeaway: Multi-tenant security is a system-wide design responsibility. Connecting cloud security controls with privacy and data lifecycle practices makes the resulting framework more useful than treating each requirement as a standalone checklist.

FedRAMP Continuous Monitoring for Healthcare SaaS: From Security Signals to Compliance Evidence

Chethna — Wed, 28 Oct 2026 12:01:59 +0000

Healthcare SaaS teams working with U.S. federal agencies need more than a secure deployment pipeline. They also need a repeatable way to monitor the authorized environment, evaluate changes, remediate vulnerabilities, and maintain evidence for ongoing security reviews.

FedRAMP Continuous Monitoring (ConMon) connects these operational activities with the requirements associated with an authorized cloud service.

Why DevOps Teams Should Care

Consider a healthcare SaaS platform that deploys application updates regularly. The team introduces a new API endpoint, updates a container image, changes an identity configuration, and modifies a database service.

These changes may be routine from an engineering perspective, but they can also affect the system's security posture or authorization boundary.

A mature monitoring program helps teams determine what changed, whether the change affects security controls, which risks require attention, and what evidence must be maintained.

1. Establish the System Boundary

Start by documenting the components within the authorized system, including relevant applications, databases, containers, infrastructure, integrations, and security services.

The boundary should be consistent with the system documentation and applicable FedRAMP requirements. Teams also need to understand which controls are inherited from cloud providers, shared between parties, or managed directly.

Without this clarity, monitoring can miss important components or create uncertainty about responsibility.

2. Connect Vulnerability Scanning With Remediation

Scanning is only one part of vulnerability management. Findings need to be validated, prioritized, assigned, remediated, and tracked according to applicable requirements.

Traditional FedRAMP Rev. 5 monitoring has included recurring configuration and vulnerability scans, monthly POA&M updates, and annual independent assessment activities. Updated vulnerability detection and response processes can change these workflows.

Engineering teams should confirm the applicable process before hard-coding reporting frequencies into internal compliance automation.

3. Treat Changes as Security Events

Not every software release is a significant change, but changes should be evaluated using documented criteria. Architectural modifications, changes to critical infrastructure, and changes affecting security controls may require additional review or notification.

A useful engineering workflow connects change tickets, deployment records, security analysis, and relevant compliance evidence.

4. Automate Evidence Collection

Useful evidence may include scan results, configuration records, remediation tickets, system inventories, assessment records, and change documentation.

Automation can reduce manual effort and improve consistency, but evidence should be validated and tied to the correct system and reporting period.

5. Keep Monitoring and Incident Response Connected

A newly disclosed vulnerability, suspicious activity, or security incident may require action across several teams. Security operations, engineering, compliance, and incident response should have clear escalation paths.

For healthcare systems, monitoring data and supporting evidence must also be handled according to applicable security and privacy requirements.

A Practical Starting Checklist

Confirm the applicable FedRAMP monitoring process.
Map the authorized system boundary.
Identify inherited, shared, and provider-managed controls.
Assign ownership for vulnerabilities and remediation.
Evaluate changes using documented criteria.
Automate collection where appropriate.
Review evidence before submitting required reports.

For further context on the evolving framework, read this overview of FedRAMP continuous monitoring requirements

Engineering takeaway: A reliable ConMon workflow turns monitoring signals into actionable security decisions and traceable evidence. It should be part of the delivery lifecycle, not an isolated compliance exercise.

Mapping PCI DSS Scope in Modern SoftPOS Architectures

Chethna — Tue, 27 Oct 2026 12:18:24 +0000

Modern payment acceptance platforms are distributed systems. A typical SoftPOS solution may combine an NFC-enabled device, a mobile application, backend APIs, transaction services, cryptographic components, cloud infrastructure, and external payment providers.

For engineering and security teams, one of the most important tasks is determining which components fall within PCI DSS scope and how architectural decisions affect the assessment boundary.

Model the Complete Payment Flow

Start with a data-flow diagram that follows the transaction from the mobile device through the relevant backend services and external payment entities.

Document:

Where payment account data enters the environment.
Which services receive, process, or transmit it.
Where data is stored, if applicable.
Where cryptographic operations take place.
Which systems administer or monitor the environment.
Which third-party services can affect payment security.

The purpose is to describe the actual architecture, not simply the intended logical design.

Distinguish Data Handling From Security Impact

Systems that store, process, or transmit cardholder data are directly relevant to the cardholder data environment. Other systems may also be in scope if they can affect CDE security or provide relevant pathways into it.

For example, a shared administrative platform might not handle payment account data directly but could control access to payment infrastructure.

Cloud environments require the same careful analysis. Separate accounts or subnets can help establish boundaries, but the security of management interfaces, identity systems, routing, and shared services must also be considered.

Use Architecture to Reduce Unnecessary Scope

A number of engineering practices can support a more manageable assessment boundary:

Segmentation: Use appropriate network controls to restrict communication between payment and non-payment environments.

Data minimisation: Avoid sending payment account data to services that do not need it.

Tokenization: Where suitable, use tokens for downstream business processes instead of exposing the original account data.

Access control: Apply least-privilege permissions and tightly manage privileged access.

Validation: Test segmentation and review whether unexpected routes or administrative pathways undermine the intended separation.

These practices can reduce exposure, but no single control automatically removes all related systems from scope.

Avoid Treating Encryption as a Scope Shortcut

Encryption is an important security measure, but encrypted data flows do not by themselves establish that a system is out of scope. The determination depends on the system's role, access, security responsibilities, and relationship to the cardholder data environment.

The same caution applies to tokenization and cloud hosting.

Account for PCI Mobile Payment Standards

PCI DSS and PCI SSC's MPoC standard address different aspects of payment security. MPoC is designed for mobile payment acceptance on commercial off-the-shelf devices.

Engineering teams should identify the standards applicable to the product rather than treating their requirements as interchangeable.

Reviewing PCI DSS requirements and scope can help teams connect architecture decisions with the appropriate assessment requirements.

Finally, scoping should be treated as an ongoing process. Changes to APIs, service boundaries, identity platforms, or remote administration can alter the security relationships between components. Keeping diagrams and technical evidence current makes scope decisions easier to explain and validate.

Applying NIST CSF 2.0 to IT/OT Security in Smart Factories

Chethna — Tue, 27 Oct 2026 12:00:34 +0000

Connected manufacturing environments create an interesting cybersecurity challenge for engineering and security teams: systems designed to manage business information increasingly interact with systems that control physical operations.

A corporate application may exchange production data with a manufacturing execution system, while engineering workstations communicate with PLCs and SCADA platforms. Remote maintenance and cloud analytics can introduce additional connections.

The result is an environment where IT and operational technology (OT) security must be considered together.

Start With Asset Discovery

Before implementing controls, teams need to understand what exists in the environment.

An industrial asset inventory should include, where relevant:

PLCs and industrial controllers.
SCADA and distributed control systems.
Engineering workstations and operator interfaces.
Industrial switches, routers, and network gateways.
Manufacturing applications and connected databases.
Remote access services and third-party connections.

The inventory should also identify system owners, criticality, communication dependencies, and operational constraints.

Without this information, teams may struggle to prioritise security investments or understand how a compromised endpoint could affect production.

Map Activities to NIST CSF 2.0

NIST CSF 2.0 provides six Functions that can organise a security programme:

Govern: Define ownership, policies, risk tolerance, and oversight.
Identify: Document assets, dependencies, and cybersecurity risks.
Protect: Apply access controls, segmentation, and secure configurations.
Detect: Monitor relevant systems and identify suspicious behaviour.
Respond: Define escalation, containment, and communication procedures.
Recover: Plan restoration of systems and critical production processes.

These Functions describe cybersecurity outcomes rather than prescribing a single technical architecture.

Design Controls Around OT Constraints

Security teams should avoid assuming that all industrial equipment can be patched, scanned, or restarted like ordinary IT endpoints.

Before conducting intrusive testing or making configuration changes, teams should consider vendor guidance, production schedules, safety requirements, and the consequences of downtime.

Network segmentation, controlled remote access, least-privilege permissions, logging, and carefully planned monitoring can help reduce exposure.

NIST SP 800-82 is a valuable complementary resource for understanding OT security considerations.

Build Repeatable Monitoring and Response

Detection should account for industrial protocols, expected operating patterns, critical system dependencies, and unusual access activity.

Incident response plans should specify who investigates alerts, who can authorise containment, and how cybersecurity decisions are coordinated with production and safety personnel.

Recovery procedures should identify critical systems, dependencies, backups, and restoration priorities.

For teams developing an organised NIST CSF 2.0 implementation, these practices provide a way to connect governance objectives with practical engineering workflows.

The goal is to create a repeatable security programme that reduces risk while respecting the availability and safety requirements of industrial systems.

SOC 2 Type 2 for SaaS Engineering Teams: Connecting Security Controls to Client Onboarding

Chethna — Tue, 27 Oct 2026 11:41:08 +0000

For SaaS engineering teams, enterprise onboarding can create a surprising amount of work outside the product roadmap. A prospective customer may ask for evidence of access management, secure development practices, vulnerability remediation, incident response, and production data protection before approving the vendor.

SOC 2 Type 2 can help organize this conversation by providing an independent examination of relevant controls over a defined period.

What Engineering Teams Need to Understand

SOC 2 Type 2 is not simply a document that a sales team requests from an auditor. The report describes controls relevant to the service organization and the applicable Trust Services Criteria.

Depending on the engagement, these controls may involve system access, change management, monitoring, incident handling, availability, confidentiality, or privacy.

Engineering teams should understand which services, environments, and systems fall within the report's scope. A report covering one product or environment should not be represented as covering every system operated by the company.

Connecting Technical Controls to Customer Questions

Enterprise questionnaires often translate technical practices into business-oriented questions. For example, a customer may ask how privileged access is restricted, how production changes are reviewed, or how security incidents are escalated.

Engineering and security teams can make these reviews easier by maintaining clear documentation and identifying evidence that supports each response.

Useful practices include:

Documenting access provisioning and removal.
Maintaining change-management records.
Tracking vulnerability assessment and remediation.
Testing incident response procedures.
Reviewing backup and recovery arrangements.
Keeping security policies and technical documentation current.

The precise controls required depend on the organization's environment and commitments.

Avoiding Common Reporting Mistakes

A SOC 2 Type 2 report does not automatically satisfy every customer requirement. Buyers may ask about controls outside the examination's scope or request additional evidence for their own risk assessments.

Teams should avoid treating a report as proof that a system is completely secure. Instead, they should explain what was examined, when the examination occurred, and which additional controls or documents are available.

Understanding SOC 2 Type 2 requirements can help engineering teams connect operational security practices with enterprise procurement needs.

When technical controls are documented and evidence is easy to locate, security reviews can become more repeatable. This allows engineering teams to spend less time reconstructing answers and more time maintaining and improving the systems they operate.

SOC 2 Type 2 for SaaS and Fintech Vendors: Preparing for US Banking Security Reviews

Chethna — Mon, 26 Oct 2026 14:51:22 +0000

For engineering-led organizations, entering the US banking market can introduce security assurance requirements that extend beyond product functionality. A bank may want to understand how the vendor manages access, protects data, responds to incidents, controls changes, and maintains service availability.

SOC 2 Type 2 can provide independent evidence about a defined set of controls. For engineering and security teams, the important work is ensuring that those controls reflect how the service actually operates.

1. Understand the Trust Services Criteria

SOC 2 examinations are based on the AICPA Trust Services Criteria:

Security: Protection of systems and information against unauthorized access and other relevant risks.
Availability: Controls relevant to service availability, when included in scope.
Processing Integrity: Controls related to complete, valid, accurate, timely, and authorized processing.
Confidentiality: Protection of information designated as confidential.
Privacy: Controls relevant to personal information and privacy commitments.

Security is the common criterion. The others should be selected based on the service, risks, and commitments rather than simply including every criterion by default.

2. Distinguish Type 1 From Type 2

A Type 1 examination evaluates control design at a particular point in time. A Type 2 examination also evaluates whether relevant controls operated effectively over a defined period.

For vendors responding to enterprise procurement requests, this difference can matter when customers want evidence about ongoing control operation rather than policy documentation alone.

3. Map Controls to the Actual Architecture

A SOC 2 scope should reflect the systems and services customers rely on. Depending on the product, this may include production applications, cloud infrastructure, identity systems, support processes, deployment workflows, relevant personnel, and third-party services.

Engineering teams should ensure that system descriptions and control documentation match the real operating environment. If architecture changes, control owners should consider whether procedures, evidence, or scope descriptions need to be updated.

4. Maintain Evidence of Control Operation

Evidence may include access reviews, change approvals, monitoring records, incident tickets, vulnerability management records, backup tests, employee training records, and vendor oversight documentation.

The specific evidence required depends on the controls and scope. Teams should avoid treating a large collection of screenshots or documents as sufficient on its own; evidence needs to show that relevant activities occurred and can be traced to the control being examined.

5. Understand Exceptions and Customer Responsibility

A SOC 2 report may include exceptions or describe complementary user entity controls—activities expected to be performed by the customer. Vendors should understand these details and explain them accurately.

A report does not guarantee that a bank will approve a vendor. Banks may request additional technical evidence, contractual commitments, security questionnaires, or information about operational resilience.

6. Prepare for Banking Procurement

US banks apply risk-based third-party due diligence. The level of review can depend on data sensitivity, service criticality, system connectivity, and the consequences of a disruption.

Organizations should identify the customer's requirements early and confirm that the planned SOC 2 scope is relevant to the service being proposed.

Conclusion

SOC 2 Type 2 is not simply a document to attach to a sales questionnaire. It is an independent report about controls within a defined scope and period.

When engineering, security, and compliance teams maintain accurate control documentation and reliable evidence, the report can become a useful part of customer assurance. Its effectiveness depends on appropriate scope, control operation, transparency about exceptions, and alignment with the bank's specific risk review.