DEV Community: Chethana M

HITRUST vs SOC 2: A Practical View for Healthcare SaaS Teams

Chethana M — Tue, 06 Oct 2026 10:43:41 +0000

If you build SaaS for healthcare customers in the US, security assurance eventually becomes part of the product conversation.

Not because customers want another badge on your website, but because enterprise buyers need evidence that vendors have appropriate controls around sensitive systems and information.

That is why SOC 2 and HITRUST frequently appear in healthcare vendor assessments.

The two should not be treated as interchangeable.

SOC 2 evaluates controls against the AICPA Trust Services Criteria. Security is required, while other criteria such as availability, processing integrity, confidentiality, and privacy can be included according to the engagement.

For a SaaS company, this makes SOC 2 useful well beyond healthcare. If the product serves several industries, a SOC 2 report can provide assurance that applies across a broad customer base.

You can explore the SOC 2 assurance offering when considering how this type of independent examination fits into a SaaS security program.

HITRUST approaches the problem differently.

The HITRUST CSF combines requirements from multiple authoritative sources into a structured framework and provides an assessment and certification model. This makes it particularly relevant to organizations operating in healthcare environments where customers may want assurance that takes healthcare-related security and privacy expectations into account.

The important part for engineering and security teams is not simply knowing that both frameworks exist. It is understanding what each one is actually demonstrating.

A SOC 2 report does not automatically equal HITRUST certification.

There may be substantial overlap in controls around identity and access management, risk management, monitoring, incident response, vendor management, continuity, and change management. However, the assessment models and requirements remain different.

This distinction becomes important when a healthcare customer asks for a specific certification.

Imagine a SaaS company already has SOC 2 Type II. A hospital procurement team then requests HITRUST. The company should not assume that its existing report closes the requirement simply because many controls overlap.

Instead, it needs to compare the existing assurance scope with the customer's expectations and the applicable HITRUST requirements.

The reverse can also happen. A company may have HITRUST certification because healthcare customers expect it, while a large enterprise customer outside healthcare requests SOC 2.

This is why mature SaaS organizations sometimes maintain both.

The decision should ultimately follow the market.

If your customers are primarily general enterprise technology buyers, SOC 2 may be central to your assurance strategy. If healthcare organizations specifically request HITRUST, that requirement needs to be considered independently.

And if the business serves both groups, maintaining multiple assurance mechanisms may make commercial sense.

The useful question is therefore not “Which framework is better?”

It is:

Which assurance evidence do our customers actually expect, and does our current control environment demonstrate it?

That question gives security, compliance, and business teams a much more practical starting point.

ISO 27001 for Philippine SMEs: Where Information Security Governance Meets Technology

Chethana M — Tue, 06 Oct 2026 10:19:35 +0000

For technology-driven SMEs in the Philippines, information security is often discussed in terms of firewalls, encryption, access controls, cloud security, vulnerability management, and monitoring.

These technologies matter.

But an organization can have a sophisticated security stack and still struggle to demonstrate that information security is being managed systematically across the business.

This is where ISO/IEC 27001 takes a different approach.

Rather than being a purely technical security standard, ISO 27001 establishes requirements for an Information Security Management System.

Technology Is Only One Part of the ISMS

An ISMS connects technology with organizational processes.

The organization defines its scope, identifies information security risks, establishes relevant controls, assigns responsibilities, monitors performance, and evaluates whether the management system continues to operate effectively.

For a Philippine software company, for example, the ISMS scope could include its development environment, cloud infrastructure, information assets, personnel, supporting processes, and customer-facing services depending on the defined certification boundary.

This creates a broader view of information security.

Organizations considering the standard can explore ISO 27001 certification to understand how the certification framework applies to an ISMS.

What Influences Certification Cost?

Technology companies often assume certification cost is primarily determined by the number of security tools they operate.

That is not necessarily the case.

Audit requirements can be influenced by factors such as:

Number of employees
ISMS scope
Number of locations
Operational complexity
Existing information security maturity
Systems and processes included within the certification boundary

A small SaaS company with one location and a clearly defined service scope can have very different certification requirements from a technology business operating across several countries.

Stage 1 vs Stage 2

The certification audit itself has two primary stages.

Stage 1 evaluates the structure of the ISMS. This includes areas such as scope, governance, documented information, and the organization's overall approach to the management system.

Stage 2 moves into operational effectiveness.

Auditors evaluate evidence to determine whether the ISMS is functioning as intended and whether the organization conforms to ISO/IEC 27001 requirements.

This distinction matters because certification is not simply a document review.

The assessment considers how the management system operates in practice.

Why This Matters for Philippine Tech Companies

Technology companies in the Philippines increasingly serve customers outside the domestic market.

A SaaS provider, software development company, BPO organization, fintech platform, or digital services business may encounter security requirements from international customers before a contract is signed.

ISO 27001 certification can provide independently assessed evidence of an organization's information security management approach.

This can become particularly valuable when responding to enterprise procurement requirements.

Certification Is Not a One-Time Technical Project

Another important point is that maintaining ISO 27001 certification requires continued attention.

Surveillance audits take place during the certification cycle to evaluate continued conformity.

The organization also needs to maintain the effectiveness of its ISMS and demonstrate continual improvement.

At the end of the cycle, recertification is required.

This means technology SMEs should think about ISO 27001 as an ongoing management system rather than a one-time security project.

A Better Way to Think About the Cost

Instead of asking only, "What is the ISO 27001 price?", businesses should first ask:

What is our intended certification scope?

How many employees and locations are involved?

How complex are our operations?

How mature is our existing information security management system?

What customer or market requirements are driving certification?

The answers to these questions provide a much clearer basis for understanding certification requirements.

For Philippine technology SMEs, ISO 27001 can therefore connect technical security practices with organizational governance, creating a recognized framework that can demonstrate how information security is managed as the business grows.

CSA STAR vs ISO 27001: A Technical Look at Cloud Security Assurance

Chethana M — Tue, 06 Oct 2026 09:54:57 +0000

Cloud environments introduce a different security model from traditional on-premises infrastructure.

Organizations may rely on shared infrastructure, virtualization, distributed services, third-party platforms, identity providers, APIs, and other interconnected technologies. This creates security considerations that cannot always be addressed through a general information security perspective alone.

That is one reason the distinction between ISO/IEC 27001 and CSA STAR matters.

Both frameworks contribute to information security assurance, but their scopes differ.

ISO 27001: The Management-System Layer

ISO/IEC 27001 establishes requirements for an Information Security Management System.

From a technical perspective, this means information security is not treated solely as a collection of security technologies.

The organization establishes a management structure around information security risks, controls, monitoring, performance evaluation, and continual improvement.

The scope can include cloud environments.

For example, a SaaS company could include its cloud infrastructure, applications, information assets, employees, processes, and supporting technologies within the defined scope of its ISMS.

This provides a broader security governance foundation.

CSA STAR: The Cloud-Specific Layer

CSA STAR approaches the problem from the perspective of cloud security.

Cloud environments have characteristics that deserve specific consideration, including:

Virtualization
Multi-tenancy
Cloud architecture
Identity and access management
Infrastructure security
Data protection
Resilience
Cloud governance
Shared security responsibilities

The Cloud Security Alliance STAR Program is designed around these types of cloud-specific considerations.

For organizations exploring this framework, CSA STAR certification provides a route toward demonstrating cloud security assurance against recognized requirements.

Why the Two Frameworks Can Work Together

The interesting part is the relationship between the two.

CSA STAR Certification Level 2 is built on an ISO/IEC 27001-certified ISMS and introduces additional cloud-focused requirements based on the Cloud Controls Matrix.

In practical terms, this creates two complementary layers.

ISO 27001 addresses the organization's broader information security management system.

CSA STAR adds a cloud-specific security perspective.

This can be particularly relevant for cloud service providers whose customers want assurance that both organizational security governance and cloud-specific risks are being addressed.

A Technical Example

Consider a cloud service provider operating a SaaS platform.

ISO 27001 can provide the broader management framework for protecting the information processed by the organization.

The provider can define its ISMS scope, evaluate information security risks, establish appropriate controls, monitor performance, and continually improve its security management processes.

CSA STAR can then provide additional assurance around cloud-specific areas.

The provider's customers may be particularly interested in how the cloud environment addresses issues such as tenant separation, cloud architecture, infrastructure security, and cloud governance.

The two perspectives answer different questions.

ISO 27001: How systematically does the organization manage information security?

CSA STAR: How does the organization demonstrate assurance around security in its cloud environment?

Choosing Based on the Architecture and Business Model

Technology architecture should be considered alongside business requirements.

A company with limited cloud exposure but significant information assets may primarily require broad information security governance.

A cloud-native organization delivering services to enterprise customers may have stronger reasons to consider cloud-specific assurance.

The customer base also matters.

Enterprise buyers frequently use security certifications as part of supplier evaluation. If a provider's customers operate in regulated sectors, they may expect more detailed evidence around cloud security.

Why Transparency Matters

CSA STAR also introduces an additional transparency dimension through the STAR Registry.

For cloud providers, publicly available assurance information can make it easier for prospective customers to evaluate the provider's security posture.

This can be commercially relevant when customers compare multiple cloud providers.

Security assurance is therefore not only a technical issue. It can influence procurement, customer confidence, and market differentiation.

Final Perspective

ISO 27001 and CSA STAR should not automatically be treated as competing technologies or certifications.

ISO 27001 establishes a broad information security management foundation.

CSA STAR focuses more specifically on cloud security assurance.

For cloud service providers, particularly those serving European enterprise customers, understanding how the two frameworks relate can lead to a more informed certification strategy.

In many cases, the strongest approach is not choosing one over the other, but determining how each framework can contribute to the organization's broader security assurance objectives.

Why Energy Data Matters in Industrial Energy Management

Chethana M — Tue, 06 Oct 2026 09:22:20 +0000

Industrial energy management increasingly depends on the quality of the data available to decision-makers.

A facility may consume electricity, fuel, steam, compressed air, or other forms of energy across dozens of processes and systems. Production equipment, HVAC, refrigeration, pumps, boilers, lighting, and utilities can all contribute to the overall energy profile.

The challenge is not simply collecting consumption figures.

The more important question is whether organizations can use energy information to understand performance and make better operational decisions.

Energy Data as an Operational Input

For an industrial organization, energy data can reveal patterns that may otherwise remain difficult to identify.

A sudden increase in energy consumption may indicate an operational change. A persistent increase could point toward inefficient equipment or processes. Comparing energy performance across different periods can also provide insight into whether specific initiatives are producing the expected results.

This makes energy measurement relevant beyond sustainability reporting.

It can become part of the information used to evaluate operational performance.

ISO 50001 provides a structured framework for this type of energy management. Organizations exploring certification can learn more about ISO 50001 energy management certification and its requirements for establishing and continually improving an Energy Management System.

The Role of Energy Performance Indicators

Energy Performance Indicators, commonly known as EnPIs, are an important concept within ISO 50001.

Rather than relying only on total energy consumption, organizations can use defined indicators to evaluate energy performance in a more meaningful way.

This matters because raw consumption figures can sometimes be misleading.

Production volumes, operating conditions, facility usage, and other factors can influence energy consumption. A structured approach to performance measurement provides a stronger basis for understanding whether energy performance is actually improving.

Connecting Data With Industrial Decisions

The technical side of energy management becomes more valuable when the resulting information reaches the right decision-making processes.

Energy performance information can contribute to decisions involving:

Production operations
Equipment performance
Maintenance priorities
Energy efficiency initiatives
Facility management
Sustainability objectives
Resource planning

The objective is not simply to create another dataset.

The objective is to make energy performance information useful.

Why This Matters for UAE Industry

For energy-intensive businesses in the UAE, the financial significance of energy consumption can make this approach particularly relevant.

Manufacturing facilities, food processors, cement operations, chemical businesses, metals companies, logistics organizations, and other industrial sectors may have multiple significant energy uses that require ongoing monitoring.

A structured Energy Management System can create greater consistency around how these energy uses are identified, measured, reviewed, and improved.

From Monitoring to Continual Improvement

Data has limited value when it is collected but never evaluated.

Effective energy management requires organizations to review performance, compare results with objectives, identify areas requiring attention, and continue evaluating improvements over time.

This creates a cycle in which measurement informs decisions and decisions influence future energy performance.

For organizations considering ISO 50001, this connection between data, operational controls, measurement, and continual improvement is an important part of the broader business case.

Energy management is therefore not only an environmental or facilities concern. In data-rich industrial environments, it can become an important component of operational intelligence.

NIST AI RMF: What Engineering Teams Should Know About AI Risk

Chethana M — Mon, 05 Oct 2026 11:56:01 +0000

AI engineering does not end when a model performs well in testing.

Once an AI system enters a real business environment, additional questions emerge. How is the system being used? What data does it depend on? Who owns decisions around it? How are unexpected outputs handled? What happens when the model, data, vendor, or use case changes?

These questions are part of the wider AI governance problem.

The NIST AI Risk Management Framework offers a useful structure for thinking about that problem.

NIST AI RMF 1.0 is a voluntary framework from the U.S. National Institute of Standards and Technology. It is designed to help organizations identify and manage AI risks while promoting trustworthy AI.

The framework is organized around four functions:

Govern establishes organizational policies, roles, responsibilities, accountability, and oversight.

Map focuses on understanding the context of an AI system, including its intended purpose, stakeholders, potential impacts, and risk environment.

Measure focuses on evaluating risks and system characteristics through appropriate testing, analysis, and monitoring.

Manage focuses on prioritizing identified risks, determining responses, and monitoring those risks over time.

For developers and engineering leaders, an important takeaway is that AI risk is broader than application security.

Depending on the system, engineering teams may need to consider data privacy, reliability, security, explainability, fairness, harmful bias, and unexpected system behavior.

The framework also recognizes that AI risk changes over time. A model that performs appropriately in one environment may create different risks after its data, users, integrations, or intended purpose changes.

This makes ongoing monitoring an important part of AI governance.

NIST AI RMF can also provide useful context when organizations are evaluating how their AI practices connect with other frameworks and standards, including cybersecurity and AI management approaches.

For a broader introduction to the framework, NIST AI Risk Management Framework: A Starter Guide for US Enterprises explains the four functions, key trustworthy-AI characteristics, and practical considerations for organizations adopting NIST AI RMF.

DPDPA vs GDPR: What Developers and Privacy Teams Should Know

Chethana M — Mon, 05 Oct 2026 11:10:22 +0000

Privacy requirements increasingly affect technical decisions.

Data collection, application architecture, APIs, cloud services, databases, analytics platforms, identity systems, and third-party integrations can all influence how an organization processes personal information.

For Indian technology companies, the DPDPA introduces an important domestic privacy framework. For businesses serving European users, GDPR may also apply.

Although both regulations address personal data protection, they should not be treated as interchangeable.

One important difference is the scope of data covered. DPDPA focuses on digital personal data, while GDPR has a broader concept of personal data and can cover certain manual processing activities.

This distinction can matter when organizations map data across applications and systems.

The two frameworks also differ in their approach to lawful processing. GDPR recognizes several lawful bases, including contractual necessity, legal obligations, legitimate interests, and consent. DPDPA relies significantly on consent while also defining specified legitimate uses.

For technical teams, individual rights can have practical implications as well. Privacy architecture may need to account for processes relating to data access, correction, erasure, and other applicable requests. The exact requirements depend on the regulation and circumstances involved.

International data flows are another major consideration.

A modern application may use cloud infrastructure, SaaS platforms, analytics services, or vendors located outside India. If European personal data is involved, GDPR's international transfer requirements may become relevant. DPDPA follows a different approach, with cross-border transfers generally permitted unless specific restrictions are introduced by the Indian government.

The result is that privacy cannot always be addressed through a single checklist.

Indian organizations serving multiple markets need to understand the regulatory context around their applications, users, data flows, vendors, and processing activities.

A useful starting point is a structured comparison of DPDPA vs GDPR, particularly when designing privacy processes for products that operate across India and Europe.

The article DPDPA vs GDPR: Key Differences Every Indian Company Must Understand explores these differences in greater detail and examines what Indian organizations should consider when determining which privacy obligations apply to their operations.

AI Governance in India: Where ISO/IEC 42001 Fits

Chethana M — Mon, 05 Oct 2026 10:51:56 +0000

AI engineering is advancing rapidly, but building an AI system is only one part of operating AI responsibly.

Organizations developing machine learning applications, generative AI products, recommendation systems, intelligent automation, or AI-enabled SaaS platforms also need to think about governance around those technologies.

This is where ISO/IEC 42001 becomes relevant.

ISO/IEC 42001 defines requirements for an Artificial Intelligence Management System (AIMS). It takes an organizational view of AI governance, covering areas such as leadership, risk management, operational processes, performance evaluation, and continual improvement.

For engineering and technology teams, this creates an important distinction. ISO 42001 is not simply a technical standard for evaluating whether a model produces accurate outputs. It considers the wider organizational environment in which AI is developed and used.

A practical starting point is building visibility into the AI landscape.

An organization may have AI in production applications, internal tools, APIs, analytics platforms, third-party services, or employee-facing generative AI tools. Understanding these different uses can influence the scope and governance requirements of the AIMS.

AI risk management also needs to extend beyond traditional application security. Depending on the system, relevant considerations can include data privacy, bias, fairness, explainability, reliability, cybersecurity, safety, transparency, and legal requirements.

Another important consideration is lifecycle management. AI governance does not stop when a model reaches production. Changes to models, data, vendors, applications, and intended use can introduce new risks that require ongoing attention.

From a certification perspective, organizations must also be able to demonstrate that their management system is operating effectively. Performance evaluation, monitoring, reviews, and continual improvement therefore become important parts of the overall system.

For Indian technology companies, ISO 42001 can provide a recognizable framework for connecting AI engineering practices with broader organizational governance.

For a more detailed look at how AI-driven organizations can approach certification, see ISO 42001 Certification in India: First Steps for AI-Driven Companies. The article covers the major ISO 42001 requirements, certification stages, common organizational challenges, and the business value of an AIMS.

SOC 2: Understanding the Assurance Standard for Service Organizations

Chethana M — Mon, 05 Oct 2026 09:16:36 +0000

As SaaS platforms, cloud services, fintech applications, and other digital services become increasingly connected to customer data, organizations are facing greater expectations around how they protect and manage that information. Customers and enterprise buyers often want more than a security statement—they want credible evidence that relevant controls have been independently evaluated.

This is where SOC 2 has become particularly relevant for service organizations.

SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA). It focuses on evaluating controls related to areas such as security, availability, processing integrity, confidentiality, and privacy, depending on the criteria selected for the engagement.

One important distinction is that SOC 2 is not technically a certification. The outcome is an independent attestation report issued following an examination of the organization's controls. Despite this distinction, terms such as "SOC 2 certification" are frequently used when organizations discuss their assurance efforts with customers and business partners.

For technology companies selling to enterprise customers, understanding this distinction can make conversations around assurance and vendor due diligence much clearer.

Why SOC 2 Matters for Technology Companies

Enterprise customers increasingly evaluate the security practices of their service providers before entering into business relationships. This can involve reviewing security controls, governance practices, risk management processes, and independent assurance reports.

A SOC 2 report can provide a structured way to demonstrate how an organization's controls address selected Trust Services Criteria.

For SaaS and cloud providers, this can be particularly valuable because customers may need assurance that information is protected throughout the systems and processes used to deliver the service.

The relevance of SOC 2 also extends beyond security alone. Depending on the scope of the engagement, organizations may address availability, processing integrity, confidentiality, or privacy as well.

SOC 2 and Independent Assurance

A key characteristic of SOC 2 is the role of an independent auditor. Rather than simply relying on an organization's own statements about its controls, the engagement provides an external evaluation of the controls within the defined scope.

This makes SOC 2 different from an internal security checklist or self-declared compliance statement.

Organizations preparing for customer due diligence can therefore use SOC 2 as part of a broader assurance strategy, particularly when customers request independent evidence of how security and related controls operate.

For a more detailed explanation of the SOC 2 definition, Trust Services Criteria, requirements, and audit process, see this SOC 2 overview(https://www.intercert.com/blogs/what-is-soc-2-definition-requirements-and-audit-process)

What Organizations Should Understand Before Pursuing SOC 2

SOC 2 is not simply about having security policies in place. The engagement considers the controls within the defined scope and whether they are appropriately designed and, where applicable, operating effectively over the examination period.

This means organizations should have a clear understanding of:

Which systems and services fall within scope
Which Trust Services Criteria are relevant
What controls address the selected criteria
What evidence demonstrates control operation
How responsibilities are assigned across teams
How control performance is monitored over time

A clear understanding of these areas can make discussions with customers, auditors, and other stakeholders more meaningful.

Building Trust Through Independent Assurance

For service organizations operating in competitive technology markets, security assurance has increasingly become part of the commercial conversation. Enterprise customers want confidence that their data is being handled through defined and consistently operated controls.

SOC 2 provides one established mechanism for demonstrating that commitment through an independent attestation report.

Understanding what SOC 2 actually evaluates—and how the resulting report differs from a certification—can help technology companies communicate their assurance position more accurately to customers and business partners.