DEV Community: Chethana M

FedRAMP for Cloud Engineering Teams: From Baseline Selection to Continuous Monitoring

Chethana M — Mon, 12 Oct 2026 09:45:15 +0000

For cloud engineering teams building or operating services intended for U.S. federal agencies, FedRAMP affects architecture, security controls, testing, documentation, and day-to-day operations. The authorization process requires more than confirming that individual security features exist. Providers must demonstrate that applicable controls are established and operating effectively within the assessed cloud environment.

Start With the Appropriate Baseline

FedRAMP has three primary baselines: Low, Moderate, and High. The selected level reflects the potential impact of a security incident involving confidentiality, integrity, or availability.

Low applies to systems where the impact would be limited. Moderate addresses environments where a compromise could seriously affect government operations or individuals. High applies to systems where a security failure could severely affect federal missions or other sensitive unclassified workloads.

The applicable baseline depends on the information being processed, the consequences of a potential incident, and the requirements of the sponsoring agency. This decision influences the scope of the security assessment and the controls the engineering team must establish.

Security Controls Have Operational Consequences

The applicable requirements may cover access control, identification and authentication, configuration management, audit logging, encryption, vulnerability management, incident response, and system monitoring.

For engineering teams, these areas have practical implications. Access permissions need to reflect authorized responsibilities. System configurations must remain controlled. Logging and monitoring need to provide relevant security information. Vulnerabilities must be identified and addressed, while incidents and changes must be handled according to the applicable requirements.

The scope and rigor of these activities depend on the selected baseline and the characteristics of the environment. Teams should consider how security controls operate across the assessed system rather than treating each control as an isolated configuration task.

Independent Assessment and Authorization

Cloud providers must provide evidence that their security controls meet the applicable requirements. A Third Party Assessment Organization (3PAO) evaluates the environment through activities that may include documentation review, technical testing, interviews, vulnerability assessments, and penetration testing.

The assessment findings are documented in a Security Assessment Report. The sponsoring federal agency or, where applicable, the Joint Authorization Board (JAB) reviews the evidence before an authorization decision is made. An Authority to Operate (ATO) may be granted if the relevant authority considers the risks acceptable.

The FedRAMP security requirements and authorization process explain the relationship between baseline selection, security assessment, and ongoing obligations.

Continuous Monitoring After Authorization

Receiving an ATO does not remove the need for security oversight. Cloud environments change as software is updated, infrastructure is modified, vulnerabilities are discovered, and new threats emerge.

Ongoing activities may include vulnerability scanning, patch management, configuration monitoring, incident reporting, security reporting, and periodic reassessments. Engineering and security teams need clear ownership of these activities so that changes do not undermine the required security posture.

Planning for the Authorization Timeline

Authorization duration depends on the impact level, system scope, existing security maturity, documentation quality, available resources, assessment findings, and government review schedules. High baselines generally involve more extensive control requirements, but the condition and complexity of the environment also matter.

For cloud engineering teams, the key consideration is lifecycle management. FedRAMP requirements affect how a service is assessed, operated, monitored, and maintained over time—not simply what must be completed before it can be used by a federal agency.

ISO 42001 for AI Teams: Managing Risk Across the AI Lifecycle

Chethana M — Mon, 12 Oct 2026 09:20:55 +0000

AI systems rarely operate as isolated models. A production AI service may involve training data, external APIs, cloud infrastructure, user interfaces, automated workflows, and third-party providers.

Each component can introduce risks that affect the system's overall behavior. For organizations using AI in Africa's growing digital economy, managing these risks requires more than model testing alone.

ISO/IEC 42001 provides a management system approach to AI governance.

What Is an AI Management System?

ISO 42001 establishes requirements for an Artificial Intelligence Management System (AIMS). It applies to organizations that develop, provide, or use AI systems and establishes a structured approach to governance, risk management, operational controls, performance evaluation, and continual improvement.

The standard connects technical AI activities with organizational accountability. This means that governance involves not only developers and data scientists but also business leaders and relevant personnel responsible for risk, operations, privacy, and compliance.

Mapping AI Risks Across the Lifecycle

Consider a business deploying an AI-powered customer service platform. Its risks may begin with the quality and suitability of training data, continue through model evaluation, and extend to the way the system responds to customers in production.

A structured AI management system considers these stages as connected activities.

Data management: Organizations consider data quality, suitability, and relevant privacy obligations.

Model evaluation: Teams evaluate whether system performance aligns with its intended use and identify potential limitations.

Human oversight: Appropriate review mechanisms can be established for decisions with significant consequences.

Monitoring: Performance and emerging risks can be evaluated after deployment.

Third-party governance: External AI services and dependencies can be considered within the organization's risk management processes.

The specific controls depend on the system, its intended purpose, and the organization's risk profile.

Understanding Annex A and Annex B

Annex A of ISO 42001 contains reference controls for AI governance. Annex B provides information on applying these controls. The two annexes complement the management system requirements by addressing concerns specific to AI.

Organizations should determine which controls are relevant rather than assume that every reference control applies identically to every use case.

ISO 42001 vs. NIST AI RMF

The NIST AI Risk Management Framework offers a voluntary approach to identifying, assessing, managing, and monitoring AI risks. ISO 42001 establishes requirements for an AI management system and allows organizations to pursue independent certification.

Teams may consider both frameworks where technical risk management and formal organizational governance serve different business objectives.

Organizations exploring ISO 42001 certification should examine their AI architecture, data flows, external dependencies, governance responsibilities, and operational risks before defining the management system scope.

For engineering teams, the key takeaway is simple: AI risk management must continue after deployment. Governance needs to account for changes in data, model behavior, system dependencies, and business use over time.

HITRUST CSF Certification: Security Controls, Scope, and Assessment Planning

Chethana M — Mon, 12 Oct 2026 08:58:08 +0000

Healthcare technology environments rarely operate in isolation. A single service may rely on cloud infrastructure, APIs, databases, identity systems, external vendors, and applications that process protected health information (PHI).

For organizations operating in this environment, HITRUST CSF certification provides a framework for demonstrating that information security and privacy controls have been independently assessed.

Understanding the HITRUST CSF

The HITRUST Common Security Framework combines requirements from multiple authoritative sources, including HIPAA, ISO/IEC 27001, NIST, and PCI DSS.

Rather than focusing on one regulation alone, the framework brings multiple security and privacy requirements into a unified structure. This is particularly relevant to healthcare vendors that face overlapping customer, contractual, and regulatory expectations.

Choosing an Assessment Pathway

The three commonly discussed options are e1, i1, and r2.

e1: A foundational cybersecurity assessment.

i1: A broader assessment focused on leading security practices.

r2: A comprehensive, risk-based validated assessment.

The choice depends on the organization's risk profile, customer expectations, regulatory obligations, and operational complexity.

Technical and Governance Areas to Consider

HITRUST assessment planning may involve several interconnected control areas:

Identity and access management: User provisioning, role-based permissions, privileged access, and periodic access reviews.

Asset management: An accurate inventory of systems, software, cloud resources, applications, and data repositories.

Risk management: Processes for identifying threats, evaluating potential business impacts, and determining risk treatment.

Incident management: Defined procedures for identifying, investigating, containing, and responding to cybersecurity events.

Third-party risk: Oversight of cloud providers, software vendors, and other organizations that may access sensitive healthcare data.

Security monitoring: Logging, incident detection, vulnerability management, and ongoing evaluation of control effectiveness.

These areas are connected. For example, an incomplete asset inventory can affect risk evaluation, vulnerability management, and the ability to determine which systems fall within the assessment scope.

What Determines Cost and Duration?

HITRUST certification does not have one universal price or timeline. Assessment type, scope, infrastructure complexity, number of locations, existing control maturity, assessor fees, and applicable HITRUST fees can all influence the total effort.

A complex r2 assessment may take several months. The duration depends on the environment being assessed and the availability of reliable evidence.

Organizations exploring HITRUST CSF certification requirements should define their intended scope and confirm which assessment pathway aligns with their customer and risk requirements.

For healthcare technology teams, the key consideration is how security controls operate across the complete environment—not simply whether individual policies exist.

CSA STAR for Cloud Providers: Controls, Levels, and Registry Visibility

Chethana M — Fri, 09 Oct 2026 09:38:19 +0000

Cloud security assessments can become difficult to compare when every provider describes its controls differently. A cloud-specific framework creates a more consistent reference for documenting security practices and communicating assurance.

CSA STAR is one such program. Developed by the Cloud Security Alliance, it focuses on security assurance for cloud services and uses the Cloud Controls Matrix (CCM) as a central reference.

The Cloud Controls Matrix

The CCM organizes controls relevant to cloud security. For cloud providers, it offers a common structure for reviewing governance and technical practices rather than treating each customer questionnaire as a completely separate exercise.

A provider can use the framework to examine how its existing security controls map to the applicable cloud-specific criteria. The extent of the assessment depends on the STAR route being pursued.

Self-Assessment vs. Independent Assessment

CSA STAR includes different assurance levels.

Level 1: A provider completes a self-assessment and may publish the resulting information in the STAR Registry. This improves transparency, but the information remains self-assessed rather than independently certified.
Level 2: A third party evaluates the provider through an applicable certification or attestation route. STAR Certification combines ISO/IEC 27001 requirements with the CCM; STAR Attestation follows a different route based on relevant attestation criteria.
Level 3: The supplied article describes this as an evolving direction centred on continuous monitoring. Current availability and scheme requirements should be confirmed before treating it as an active certification path.

These distinctions matter when a customer asks what a STAR listing actually demonstrates. A public record of self-assessment and an independent third-party assessment do not provide identical assurance.

What the STAR Registry Adds

The STAR Registry makes participating providers’ security assurance information publicly accessible. This gives customers a reference point during vendor evaluation and can reduce ambiguity about what information a provider has disclosed.

A listing alone does not establish that every customer requirement is met. The service scope, data types, contractual responsibilities, and the customer’s risk profile remain important.

Where ISO/IEC 27001 Fits

ISO/IEC 27001 establishes requirements for an Information Security Management System. CSA STAR applies additional cloud-focused criteria through the CCM. For a provider already maintaining an ISMS, the relationship between these frameworks is worth examining when determining an appropriate assurance route.

The CSA STAR certification framework outlines the program at a high level and provides a useful reference when comparing its cloud assurance options.

ISO 27001 for UAE SaaS Startups: How Cloud Complexity Affects Certification Cost

Chethana M — Fri, 09 Oct 2026 09:05:20 +0000

SaaS security rarely sits within a single application or server. A typical environment may include cloud infrastructure, APIs, CI/CD pipelines, identity systems, third-party integrations, remote employees, and production workloads.

For SaaS startups in the UAE considering ISO 27001 certification, this complexity is an important factor in certification planning.

The Connection Between Architecture and Audit Scope

ISO 27001 establishes requirements for an Information Security Management System (ISMS). Certification evaluates whether the organization's ISMS conforms to the standard within the defined scope.

That scope matters. A SaaS provider needs to understand which services, teams, locations, and information assets are relevant to the system being certified.

A narrow, clearly justified scope may require less audit effort than a broad scope covering multiple business units and operational environments. However, the scope must accurately represent the activities and information security responsibilities being evaluated.

Which Technical Factors Can Affect Cost?

Cloud infrastructure: Multiple environments, production regions, and complex cloud configurations can increase the effort required to understand the operating environment.

Identity and access management: Auditors may examine how access privileges are assigned, reviewed, and controlled.

Software development: Development pipelines, code repositories, change management, and release processes may fall within scope.

Third-party dependencies: Cloud providers, external service providers, and integrations can introduce additional information security considerations.

Operational maturity: Existing asset inventories, risk registers, incident records, and security responsibilities can influence how efficiently an organization demonstrates conformity.

Think Beyond the Initial Certification Audit

Certification costs should account for surveillance audits and the continued operation of the ISMS. Security practices must remain part of normal business operations rather than becoming an activity undertaken only before an audit.

For technology founders, this makes certification planning both a security and a commercial decision. Enterprise customers may consider independent certification when reviewing SaaS vendors that process confidential business information.

The key takeaway: certification costs depend not only on headcount, but also on scope, architecture, operational complexity, and the audit effort required to evaluate the ISMS.

PCI DSS v4.0: A Technical Checklist for African Payment Environments

Chethana M — Thu, 08 Oct 2026 06:51:23 +0000

The payment ecosystem is becoming increasingly digital across Africa. E-commerce platforms, fintech applications, retailers, hospitality businesses, and other merchants are processing more card transactions through interconnected systems.

That creates a larger technical environment in which cardholder data must be protected.

PCI DSS v4.0 updates the security requirements for these environments and introduces greater emphasis on continuous security, authentication, risk analysis, vulnerability management, and third-party relationships.

Identify the Cardholder Data Environment

Start by determining which systems are connected to payment card processing.

Depending on the business model, this may include:

POS systems
E-commerce applications
Payment gateways
Databases
Cloud infrastructure
Network devices
Mobile applications
Administrative systems
Third-party payment services

The purpose is to establish an accurate understanding of the environment before evaluating individual controls.

Map Cardholder Data Flows

Knowing that a system handles payments is not enough.

Organizations should understand how payment information moves between applications, networks, databases, payment processors, and external services.

Data-flow diagrams can provide useful visibility into these relationships and identify unnecessary paths through which sensitive information could travel.

Review Authentication

PCI DSS v4.0 increases attention on authentication security.

Technical teams should review:

MFA
Privileged accounts
Remote access
Password requirements
User authentication
Account lifecycle processes
Administrative access

The objective is to reduce the likelihood that compromised credentials can provide unauthorized access to the cardholder data environment.

Examine Network Security

Network controls remain fundamental to payment security.

Review firewall rules, segmentation, wireless configurations, remote access, network devices, and traffic monitoring.

Effective segmentation can also reduce the systems included within the cardholder data environment when properly designed and validated.

Strengthen Vulnerability Management

Payment environments should be regularly evaluated for security weaknesses.

Relevant activities can include vulnerability scanning, patch management, secure configuration reviews, penetration testing where applicable, malware protection, and monitoring for emerging threats.

The goal is not merely to identify vulnerabilities but to maintain a repeatable process for addressing them.

Protect Sensitive Data

Organizations should evaluate how cardholder information is protected while stored and transmitted.

Areas for technical review include:

Encryption
Cryptographic keys
Secure protocols
Tokenization
Data masking
Data retention
Access restrictions

Reducing unnecessary storage of sensitive information can also reduce exposure.

Monitor Security Events

PCI DSS v4.0 places greater emphasis on ongoing security.

Technical teams should maintain appropriate visibility into authentication events, privileged activity, configuration changes, system events, and other relevant security signals.

Monitoring can provide earlier detection of suspicious behavior and support incident investigation.

Review Third-Party Connections

A merchant may depend on multiple external providers.

For example, a transaction may involve an e-commerce application, payment gateway, hosting platform, processor, and other services.

The security responsibilities associated with each relationship should be understood clearly. Third-party involvement does not automatically remove the merchant's own responsibilities under PCI DSS.

Test Incident Response

Technical controls cannot eliminate every security incident.

Organizations should therefore test their incident response processes and establish clear responsibilities for detection, escalation, investigation, communication, containment, and recovery.

Testing can reveal weaknesses before an actual payment security incident occurs.

Maintain Evidence

PCI DSS compliance requires organizations to demonstrate that applicable security controls are operating effectively.

Evidence may include technical configurations, logs, scan results, testing records, access reviews, monitoring records, and other relevant information.

Maintaining accurate evidence throughout the year is more practical than attempting to recreate security activities immediately before an assessment.

Why PCI DSS v4.0 Matters

The updated standard reflects a shift toward continuous security rather than periodic compliance activity.

For African merchants, this is particularly relevant as payment environments become more interconnected and dependent on cloud services, digital platforms, and third-party providers.

A detailed PCI DSS v4.0 requirements overview provides additional context for organizations reviewing their payment security environment.

The key technical principle is straightforward: know where payment data goes, control who can access it, protect it throughout its lifecycle, monitor the environment, and continuously verify that security controls remain effective.

FedRAMP vs StateRAMP: A Technical Overview for Cloud Providers

Chethana M — Thu, 08 Oct 2026 06:22:10 +0000

Cloud providers serving U.S. government customers need to account for security requirements that extend beyond conventional commercial contracts. Two programs commonly associated with government cloud security are FedRAMP and StateRAMP.

Although they share several technical foundations, they address different government environments.

FedRAMP

FedRAMP is the federal government's standardized approach to cloud security authorization. It applies to cloud products and services used by U.S. federal agencies.

The program incorporates NIST security controls and requires structured security assessment, authorization, and continuous monitoring. Independent assessment by a qualified third party is an important element of the process.

FedRAMP also uses defined security baselines, including Moderate and other impact levels applicable to different types of federal information.

StateRAMP

StateRAMP focuses on cloud services used by state, local, tribal, and education organizations.

Its security model also draws on NIST-based practices and emphasizes independent evaluation and ongoing monitoring. The program is intended to create a more consistent approach to cloud security verification across government entities outside the federal environment.

Why the Difference Matters Technically

A provider may have strong technical controls that align with both programs, but that does not mean authorization under one program automatically satisfies the requirements of the other.

The differences can involve:

Governance
Authorization or verification pathways
Procurement requirements
Security baselines
Assessment expectations
Government customer requirements

The scope of the cloud environment and the government information being processed can also influence the applicable security requirements.

Choosing Based on Customer Type

The most practical starting point is the intended customer segment.

Federal agencies point toward FedRAMP. State, local, tribal, and education customers point toward StateRAMP.

Providers targeting both markets should compare the applicable requirements instead of assuming that one program provides universal government coverage.

The FedRAMP vs StateRAMP comparison provides additional detail on the security, governance, authorization, and procurement differences.

Final Thought

From a technical perspective, FedRAMP and StateRAMP have significant overlap. From a market and governance perspective, they are distinct.

Cloud providers should therefore evaluate both dimensions when determining which program aligns with their public-sector strategy.

The SOC 2 Question Philippine BPOs Cannot Treat as Only a Security Question

Chethana M — Wed, 07 Oct 2026 11:15:16 +0000

A Philippine BPO can have strong operations, competitive pricing, experienced teams, and international customers.

Yet one question can still appear during procurement:

How can the customer verify that its information is protected?

SOC 2 enters that conversation because it provides independent assurance around an organization's control environment.

For BPOs and IT-enabled service providers, the issue is especially relevant because outsourced operations can involve customer records, financial information, HR processes, technical environments, cloud platforms, and other sensitive information.

SOC 2 evaluates applicable controls against the AICPA Trust Services Criteria. Security is mandatory. Availability, Processing Integrity, Confidentiality, and Privacy can also be included depending on the organization's services and objectives.

The report type then changes the level of assurance.

Type 1 focuses on control design at a particular point in time.

Type 2 examines control design and operating effectiveness over a defined period.

That difference becomes significant when a prospective customer wants evidence of consistent control operation rather than a snapshot.

The broader SOC 2 question is therefore not simply whether a company has security policies or technologies. It is whether governance, access controls, monitoring, incident response, customer-data protection, third-party oversight, and related processes operate as part of a coherent control environment.

For Philippine organizations targeting international customers, understanding the SOC 2 certification process in the Philippines can provide useful context before deciding which report type and Trust Services Criteria are appropriate.

As outsourcing relationships become more security-conscious, independent assurance can become part of the commercial credibility of a service provider—not simply an item on a compliance checklist.

CMMC vs NIST 800-171: The Difference Between Controls and Verification

Chethana M — Wed, 07 Oct 2026 10:55:06 +0000

When discussing DoD cybersecurity, CMMC and NIST SP 800-171 are often mentioned as if they were interchangeable.

They are not.

The distinction becomes clearer when viewed from a security architecture perspective:

NIST SP 800-171 defines the security requirements.

CMMC defines how applicable cybersecurity practices are verified.

That distinction matters for organizations handling Controlled Unclassified Information.

NIST 800-171 as the Security Baseline

NIST SP 800-171 establishes security requirements for protecting CUI in non-federal systems.

The requirements span fourteen security families, ranging from access control and identification/authentication to configuration management, incident response, risk assessment, security assessment, and system integrity.

From a technical perspective, these requirements touch multiple layers of the environment.

Identity controls, endpoint configuration, logging, incident response, network protection, physical security, personnel processes, and risk management all contribute to the protection of CUI.

The result is not a single security product or control set. It is a broader cybersecurity requirement structure.

CMMC Introduces Assessment

CMMC 2.0 adds the verification layer.

The program is designed to determine whether contractors have established the cybersecurity practices required for protecting FCI and CUI.

Depending on contractual requirements, verification may involve self-assessment, third-party certification assessment, or government-led assessment.

For security teams, this introduces an important operational distinction.

A control can exist in theory without being consistently operational in practice.

CMMC places greater emphasis on demonstrating that applicable practices are established and operating effectively.

Why the NIST Overlap Matters

CMMC Level 2 is aligned with the 110 security requirements in NIST SP 800-171 Rev. 2.

This creates substantial technical overlap.

Areas such as MFA, access management, audit logging, incident response, configuration management, vulnerability management, system monitoring, and media protection appear within the shared security landscape.

For organizations preparing for CMMC Level 2, this means the NIST requirements should form a central part of their security architecture.

Evidence Is Part of the Security Story

Technical controls alone do not tell the entire story.

Organizations need objective evidence that applicable cybersecurity practices operate consistently over time.

Consider access control as an example. It is one thing to configure identity and access mechanisms. It is another to demonstrate that account management, authentication, authorization, and related processes are consistently maintained and monitored.

The same principle applies to incident response, configuration management, risk management, and security monitoring.

Scope Changes Everything

CUI scope can significantly affect the assessment environment.

If CUI exists across multiple applications, endpoints, cloud environments, or third-party services, each relationship can affect the boundaries of the environment under consideration.

A clearly defined CUI environment therefore becomes an important starting point for understanding the applicable cybersecurity requirements.

The Bottom Line

CMMC and NIST 800-171 should not be treated as competing standards.

NIST 800-171 establishes the underlying cybersecurity requirements, while CMMC provides a formal verification structure for applicable DoD contracts.

Understanding this relationship allows security and compliance teams to design their cybersecurity programs with both operational requirements and assessment expectations in mind.

ISO 42001 vs EU AI Act: Where AI Governance Meets Regulation

Chethana M — Wed, 07 Oct 2026 10:35:54 +0000

AI systems are increasingly connected to enterprise data, applications, workflows, and decision-making processes. As their role expands, security and governance teams need to think beyond model behavior.

The larger question becomes:

How should an organization govern AI while also meeting the regulatory requirements that apply to its systems?

For organizations operating in Europe, two frameworks are particularly relevant: ISO/IEC 42001 and the EU AI Act.

They address different layers of the problem.

EU AI Act: The Regulatory Layer

The EU AI Act establishes legally binding obligations for AI activities within its scope.

Its risk-based approach means that regulatory requirements depend on factors such as the AI system's classification and the organization's role.

For applicable higher-risk systems, requirements can involve risk management, data governance, technical documentation, human oversight, transparency, accuracy, cybersecurity, and post-market monitoring.

From an engineering perspective, this means that compliance considerations can extend beyond the model itself.

The surrounding data, processes, interfaces, documentation, monitoring, and human controls can all become relevant.

ISO 42001: The Management-System Layer

ISO 42001 approaches AI governance from the organizational level.

It establishes an Artificial Intelligence Management System designed to manage AI-related activities throughout their lifecycle.

The management-system approach introduces structured processes around leadership accountability, AI risks, policies, objectives, lifecycle governance, monitoring, and continual improvement.

This creates an organizational layer around AI systems rather than focusing exclusively on individual technical components.

The Important Boundary

The two frameworks should not be treated as equivalent.

ISO 42001 certification does not automatically establish compliance with the EU AI Act.

An organization can have a certified AIMS and still have specific EU AI Act obligations that require separate evaluation.

This distinction is particularly important in complex AI environments where different systems may have different regulatory classifications.

Bringing the Layers Together

A stronger governance architecture can connect the two.

At the organizational layer, ISO 42001 can establish governance structures, ownership, risk processes, monitoring, and lifecycle oversight.

At the regulatory layer, the EU AI Act can determine the obligations applicable to particular systems and organizational roles.

This creates a model where governance is structured centrally while regulatory requirements are evaluated according to individual AI use cases.

Such an approach becomes increasingly relevant as AI systems interact with enterprise applications, external data sources, automated workflows, and third-party services.

Why Lifecycle Governance Matters

AI governance cannot stop when a model enters production.

AI systems can change through retraining, new data, configuration changes, new integrations, altered use cases, or changes in the surrounding business environment.

ISO 42001's management-system perspective emphasizes ongoing monitoring and continual improvement, while the EU AI Act introduces obligations that can extend throughout the lifecycle of applicable AI systems.

This makes lifecycle governance an important connection point between the two frameworks.

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.