Determining the in-scope headcount for your ISO 27001 Information Security Management System (ISMS) is an essential step in preparing for certification. Your headcount reflects the number of people directly involved in performing the processes covered by your ISMS, and its accuracy influences the required audit time and overall management of the ISMS.  

Ensuring this headcount is well-defined and comprehensive will streamline your audit, help your certification body adequately budget time for the audit process, and support the successful implementation of security measures aligned with your business operations. 

The term “in-scope headcount” refers to the employees and contractors directly involved in performing the activities governed by your ISMS. This includes people across various departments who contribute to the development, maintenance, and security of the systems, processes, or services within the defined scope.  

For example, if your ISMS covers the development and operation of a Software-as-a-Service (SaaS) application, your in-scope headcount would include developers, DevOps engineers, system administrators, and, depending on how they interact with the development process, potentially corporate IT. 

When identifying your in-scope headcount, consider these critical factors: 

Step 1: Identify Core ISMS Processes 

Start by identifying the processes that fall under your ISMS. For example, if your ISMS covers a SaaS platform, you would include software development, operations, and maintenance. Focus on the roles directly involved in these processes. 

Step 2: List Departments Involved 

Once the core processes are defined, determine which departments or teams are responsible for these activities.

Step 3: Map Dependencies 

Evaluate the dependencies between departments. For example, if corporate IT provides critical support for the SaaS platform’s security or infrastructure, they should be included in the in-scope headcount and noted within the scope statement interfaces and dependencies. 

Step 4: Include External Parties 

If any external contractors, consultants, or service providers are responsible for aspects of the ISMS processes (e.g., outsourced security monitoring), be sure they are accounted for in the headcount. 

Step 5: Determine Your In-Scope Headcount 

While it’s not a requirement of the standard to document your headcount formally, you should have a clear number in mind to provide your certification body. This headcount is essential for helping them accurately determine the number of days required for the audit and ensuring that all critical components of your ISMS are covered. 

In many cases, departments like sales, marketing, or customer service may have little to no impact on the ISMS and can often be excluded from the headcount. These departments typically do not handle sensitive information or perform activities that fall within the ISMS’s security scope. However, it’s important to assess each department based on their involvement with information security to ensure there are no overlooked risks. 

While it’s common to exclude non-relevant departments, some organizations choose to include the entire company within the ISMS scope. If you decide to include all departments, including those with minimal information security involvement, there are options to reduce the audit days based on the reduced risk associated with certain activities.  

In these cases, you should speak with your certification body to explore opportunities for reducing audit time while ensuring the ISMS remains effective and compliant. 

In many cases, multiple departments contribute to the activities under your ISMS. Involving cross-departmental teams during the headcount determination process ensures no critical roles are overlooked.  

Collaboration across departments can also help identify any indirect roles that contribute to maintaining the security of information assets or systems. By involving stakeholders from different areas, such as HR, IT, and legal, you ensure a more comprehensive view of who should be included in the ISMS scope. 

By carefully identifying the personnel involved, whether selectively or company-wide, and documenting their roles clearly, you can optimize the audit process and align your ISMS with both business and security objectives. 

If you have questions about defining your ISO audit scope or need assistance with your compliance efforts, we’re here to help.  

With climate considerations playing a larger role in corporate risk management and strategic planning, the ISO/IEC 27001 cybersecurity standard has been updated to include the potential impacts of climate change on an organization’s Information Security Management Systems (ISMS).

Under an amendment issued in February 2024, organizations preparing for an ISO/IEC 27001 audit are required to consider the potential risks climate change can present to their ISMS, as well as any potential implications for interested parties.

In a joint statement, ISO and the International Accreditation Forum highlighted the need for organizations to consider the effects of climate change on their ability to achieve the intended results of the management system.

The statement explained that some climate-related risks, such as regulatory compliance or organizational resilience, may have a general effect on an organization’s ISMS. Some organizations will face more specific climate-related ISMS risks related to their industry (such as energy production or agriculture) or factors such as their geographic location.

The ISO/IEC 27001 standard adds two references to climate change within Clause 4, “Context of the Organization.” Clause 4.1 (Understanding the Organisation and its Context) adds a sentence reading “The organisation shall determine whether climate change is a relevant issue.” Clause 4.2 (Understanding the Needs and Expectations of Interested Parties) adds the sentence “Relevant interested parties can have requirements related to climate change.”

The changes are designed to help organizations address several climate-related risks to their ISMS and its operations. If, for instance, a severe weather event such as a windstorm or flooding affects an organization’s data center, the availability of its systems and data can be disrupted.

Similarly, vendor or supply chain disruptions following climate-related events could affect an organization’s ability to maintain an ISMS and its performance. Customers may also have concerns about whether a climate-related disruption to a service organization can affect their operations.

To comply with the revised standard, organizations need to consider whether climate change can affect their ISMS, and whether they’ve implemented controls or other measures to address climate-related risks. For many organizations without material climate exposures, this can be addressed with language similar to:

“The organization acknowledges the potential impact of climate change on its operations and has considered these risks in the context of its Information Security Management System (ISMS). While no specific mitigation actions are committed at this stage, the organization remains aware of climate-related factors that may affect its business environment.”

Similarly, organizations should also consider addressing climate risk with policy statements in their Management System’s risk assessment documentation. Management should include language saying it has considered the impact of climate risk on the ISMS and whether that risk meets a threshold for mitigation. (If it does, the organization should outline the mitigation measures it has taken.)

If an organization has more than one ISO/IEC Management System, it needs to conduct separate climate risk assessments for each one.

To learn more about ISO 27001 certification and its valuable role in helping your organization protect its systems and information, contact us.

Organizations must handle personally identifiable information (PII) data responsibly within their networks and cloud services to maintain trust with customers and business partners, while complying with an expanding array of state and international laws and regulations.

The ISO/IEC 27701 and ISO/IEC 27018 standards provide valuable guidance in helping organizations improve privacy data security and regulatory compliance—and build trust and credibility with customers and prospects—by aligning their data-protection policies, procedures, and controls with recognized global frameworks.

The ISO/IEC 27701 standard guides organizations on managing personal information securely. The standard extends ISO/IEC 27001, which focuses on general information security, by adding specific requirements for handling personal data. 

ISO/IEC 27701, applicable to any entity that processes or controls personal information, builds on the extensive security practices outlined in ISO/IEC 27001 by focusing on privacy management that provides guidance on handling personal data responsibly.

The ISO/IEC 27018 standard, which provides guidelines for protecting personal data in cloud services, is designed for cloud service providers who process data on behalf of others. This standard helps ensure that personal information stored or processed in the cloud is secure.

By ensuring data privacy in cloud services, complying with the standard helps providers build trust and confidence with customers and prospects.

Both standards offer strong data protection guidance designed to help companies secure personal information against unauthorized access, alteration, theft, or destruction. Organizations that are certified against 27701, or in compliance with 27018, demonstrate compliance with legal and regulatory requirements for maintaining information security and customer privacy, as well as an ongoing commitment to safeguarding the data they’ve been entrusted to process and store.

Both standards are based on ISO/IEC 27001 and use that general information security framework as a foundation.

The two standards differ in the scope of their application. ISO/ICE 27701, for instance, is a certifiable standard. With ISO/IEC 27018, auditors are evaluating the organization’s compliance with the standard.

ISO/IEC 27701 applies broadly to any organization handling personal data, including data controllers and processors. This can include any organization, regardless of its industry or size, that wants to approach information security management systematically. The standard’s framework can be adapted to the specific needs of each organization seeking certification.

In contrast, ISO/IEC 27108 applies specifically to organizations that process PII in public cloud environments. These can be cloud service providers that process PII on behalf of their customers or provide support services for cloud service providers.

It can also be applicable to organizations that handle personal data in cloud environments, such as companies that develop or provide security software or services to protect PII in the cloud.

The standards also have a different regulatory alignment. ISO/IEC 27701 is aligned with several global privacy regulations, offering a comprehensive framework.

By providing guidelines for protecting PII, 27701 aligns with several global privacy regulations, including the EU’s General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and other regional privacy laws.

Most acts share broad principles such as mandating data protection and privacy controls, restrictions on data use or sharing without consumer consent, transparency in data processing, and similar provisions.

The standards also differ in their timing. Including ISO/IEC 27018 essentially adds one additional day to an in-progress ISO/IEC 27001 audit. A 27701 certification can add from 2.5 days to 50% additional time to their 27001 audit if the organization under review is a processor and controller of PII.

Both ISO/IEC 27701 and ISO/IEC 27018 are important for protecting personal information, but they serve different purposes. ISO/IEC 27701 offers a broad framework for privacy management that’s suitable for any organization. ISO/IEC 27018 provides specific guidance for cloud service providers to protect data in the cloud.

Understanding your organization’s needs, along with customer and regulatory expectations, will help you choose the right standard to enhance your data protection efforts.

Contact us to learn more about ISO/IEC 27701 and 27018.

As artificial intelligence (AI) continues to transform industries, understanding the roles within the AI lifecycle— production, development, provision, and use—is crucial for organizations involved in AI development, deployment, and usage to manage risk effectively and obtain ISO/IEC 42001 certification.

These roles are defined in the ISO/IEC 42001 and ISO/IEC 22989 standards, which offer a clear breakdown of the key responsibilities within the AI ecosystem. By adopting ISO compliance, organizations can demonstrate their commitment to responsible AI development and usage. This can enhance trust with stakeholders, mitigate risks, and improve overall performance.

Each role is distinct, so it is important to understand their contributions and responsibilities to ensure the creation, implementation, and application of AI systems meet the organization’s goals while maintaining high standards of reliability and performance.

The ISO 42001 standard provides guidance for successful development and use of an Artificial Intelligence Management System (AIMS), including creating and documenting effective policies, processes, and controls. An ISO 42001 certification audit will examine several areas, including AI-specific ethical, security, and operational considerations, system lifecycle management, performance optimization, documentation, and others.

To achieve ISO/IEC 42001 certification, an organization needs to be able to define their role within the AI ecosystem. An organization can perform more than one of the roles listed below.

An AI producer is an organization or entity responsible for designing, developing, testing, and deploying products or services that use one or more AI systems. This role involves the full lifecycle of AI creation, from conceptualizing the AI model to putting it into practical use in real-world applications. AI producers are critical in ensuring AI systems are not only functional, but also meet specified performance and ethical guidelines.

An AI provider focuses on enabling access to AI technologies for other organizations, either by offering AI platforms or delivering specific AI services or products. This role is essential for making AI technologies widely available and supporting stakeholders in building, deploying, and using AI.

An AI user is any organization or entity that uses AI products or services, either directly or as part of its operations. AI users leverage AI to automate processes, gain insights, improve decision-making, or enhance products and services. This role encompasses a wide range of activities, from companies using AI-driven software for internal operations to those deploying AI in customer-facing solutions.

AI users rely on the outputs of AI systems, without necessarily being involved in the technical development of those systems. They focus on applying AI tools and services to improve organizational efficiency, product quality, or service delivery. In doing so, they play a crucial role in realizing the benefits of AI technologies across various industries.

Understanding the specific roles within the AI lifecycle is vital for organizations involved in any part of AI development, provision, or use. The AI producer designs and deploys AI models, with the AI developer playing a key role in implementing and verifying these models. The AI provider enables access to AI services and platforms, while the AI user applies these technologies to achieve operational and business goals.

By defining these roles clearly, organizations can collaborate, allocate resources, and streamline their AI strategies more effectively and facilitate ISO 42001 compliance. Whether building an AI model, offering AI services, or using AI solutions, each role is essential to the broader AI ecosystem.

With AI continuing to evolve, the distinctions between these roles will help organizations manage their AI initiatives more effectively, ensuring that AI technologies are developed, delivered, and applied in ways that maximize their potential impact.

To learn more about ISO compliance within AI applications, contact us.

What Is the Audit Scope?

Key Considerations When Defining the Scope

5 Steps to Define the Audit Scope

How to Write Your Scope Statement

Common Pitfalls to Avoid When Defining Your Scope

The Role of Stakeholders

Defining the scope of your ISO 27001 Information Security Management System (ISMS) or Privacy Information Management System (PIMS) is a crucial early step for certification. The scope sets the boundaries of what your audit will cover, ensuring your most valuable information and processes are protected and aligned with your business goals.

After defining your scope, the next step is creating a scope statement—a concise declaration that will appear on your certification certificate. This statement outlines the specific boundaries within which your ISMS or PIMS operates and publicly affirms your commitment to information and privacy security.

Your audit scope defines the parts of your organization, processes, locations, and information assets included in your ISMS or PIMS. This scope must be clear and aligned with your business objectives to ensure your ISMS/PIMS is operating ethically and is effective in protecting your critical information.

A well-defined scope helps your organization focus its efforts where they matter most and makes the certification process smoother by preventing unnecessary complexity.

When defining your audit scope, consider these key factors:

Step 1: Analyze Your Organizational Context

Understand the business objectives, stakeholders, and legal requirements that may impact your information security or PIMS.

Step 2: Identify Critical Assets and Processes

List key digital and physical assets, as well as processes vital to your operations. Focus on what needs protection.

Step 3: Define Boundaries

Clearly outline the geographical and operational boundaries of your ISMS or PIMS. Specify which departments or locations are covered.

Step 4: Consider External Parties

Assess third-party relationships. Include any vendors or service providers that may impact your information security or PII.

Step 5: Document Your Scope

Write a clear document covering all locations, processes, and assets within your ISMS and PIMS. This will form the basis for your scope statement.

Once you’ve defined your scope, it’s time to write your scope statement. This statement, which will appear on your certificate, is a public declaration of what is covered by your ISMS or PIMS. It should be clear and concise and reflect the boundaries you’ve established.

The scope of certification encompasses the Information Security Management System (ISMS) governing [insert key processes, services, or products covered by the ISMS, e.g., the organization’s SaaS application]. This includes [list key activities or departments involved, e.g., the design, development, deployment, and maintenance of the application]. The organization [insert operational details, e.g., operates entirely remotely / has operations across multiple sites / includes specific locations], with [insert any relevant details about physical locations, e.g., a designated mailing address used solely for correspondence purposes].

This certification aligns with ISO 27001 standards and is based on the Statement of Applicability (SoA) [insert version number and date, if desired—e.g., version 1.1 dated March 25, 2024].

Key Processes, Services, or Products:

Clearly state what the ISMS governs. This might include specific products (e.g., a SaaS application), services (e.g., managed IT services), or general operations (e.g., data processing).

Activities or Departments Involved:

List the activities or departments included in the scope. This could involve the design, development, maintenance, operations, support, or other relevant activities tied to information security.

Operational Details:

Specify whether your organization operates remotely, across multiple sites, or in specific locations. If the organization is remote, mention any physical mailing addresses and clarify if these are not operational locations.

Statement of Applicability (SoA) (Optional):

Including the SoA version and date is common but optional. If included, mention the version and date of the SoA your certification is based on.

Sample Scope Statement for ISO 27001 (ISMS) with locations

The scope of certification encompasses the Information Security Management System (ISMS) governing the organization’s “SecureVault 360” cloud-based data security and storage solution. This includes the development, operation, and customer support processes involved in managing the “SecureVault 360” platform. The organization operates across three sites in the United States and Europe, with the headquarters located in Austin, Texas. This certification aligns with ISO 27001 standards and is based on the Statement of Applicability (SoA) version 2.0 dated January 10, 2024.

Sample Scope Statement for ISO 27001 (ISMS) for a Remote Organization

The scope of certification encompasses the Information Security Management System (ISMS) governing the organization’s “SecureVault 360” cloud-based software development services. This includes the design, development, deployment, and support processes related to the “SecureVault 360” platform. The organization operates entirely remotely, with no physical office locations. The designated mailing address in New York, NY, United States, is used solely for correspondence purposes. This certification aligns with ISO 27001 standards and is based on the Statement of Applicability (SoA) version 3.0 dated April 1, 2024.

ISO 27701 Privacy Information Management System (PIMS) Scope Statement Samples

In addition to the ISO 27001 scope statement examples, it’s also useful to explore how organizations can define their scope under ISO 27701. As an extension to ISO 27001, ISO 27701 focuses specifically on privacy management for organizations acting as data controllers, processors, or both. Below, you’ll find sample scope statements for ISO 27701 to help you navigate this area effectively.

ISO 27701 (PIMS) Scope Statement Template

The scope of certification encompasses the Privacy Information Management System (PIMS) governing [insert key processes, services, or products covered by the PIMS, e.g., the organization’s data processing and privacy management operations]. This includes [list key activities or departments involved, e.g., the collection, processing, storage, and management of personal data]. The organization [insert operational details, e.g., operates entirely remotely / has operations across multiple sites / includes specific locations] and functions as a [declare whether the organization is a data controller, processor, or both]. This certification aligns with ISO 27701 standards and is based on the Statement of Applicability (SoA) [insert version number and date, if desired—e.g., version 1.1 dated March 25, 2024].

Sample Scope Statement for ISO 27701 (PIMS)

The scope of certification encompasses the Privacy Information Management System (PIMS) governing the organization’s customer data management services for “SecureVault 360,” a cloud-based data security and storage solution. This includes the collection, processing, storage, and deletion of personal data related to the “SecureVault 360” platform. The organization operates as both a data controller and data processor, with operations across three sites in the United States and Europe, including headquarters in Austin, Texas. This certification aligns with ISO 27701 standards and is based on the Statement of Applicability (SoA) version 2.0 dated January 10, 2024.

This template provides a flexible structure that can be customized to fit various organizational contexts and will help in crafting a clear and comprehensive ISO 27001 or ISO 27701 scope statement.

When defining your scope, watch out for these pitfalls:

Defining your ISO 27001 or 27701 scope and writing your scope statement shouldn’t be done in isolation. Involve key stakeholders, including senior management, IT teams, legal advisors, and department heads. Collaboration ensures the scope is comprehensive, realistic, and aligned with your organization’s goals.

Defining your audit scope and writing a clear scope statement are key steps toward certification. By understanding your organization’s context, identifying key assets and processes, and involving stakeholders, you can create a scope that aligns with your business objectives and protects valuable information.

This article offers a proven approach to help you get started, but every organization is unique. Be sure to explore additional resources or seek professional advice to tailor your scope statement to your specific needs.

Penetration testing plays an important role in compliance audits as well as ongoing security reviews by helping organizations identify, assess and remediate security vulnerabilities. Also known as a pen test, a penetration test is a security evaluation or exercise performed to discover security weaknesses that malicious actors could use to gain access to an organization’s systems and sensitive data.

Penetration testing is also informally called “ethical hacking” because the goal of the test is to remediate vulnerabilities, not to perform malicious actions.

Penetration testing is a vital part of an organization’s cybersecurity strategy. It helps organizations identify and fix security weaknesses before criminals can exploit them.

For compliance purposes, pen testing is conducted to help organizations meet well-known industry standards and frameworks, such as SOC, ISO, HITRUST, FedRamp, PCI, or other frameworks.

In this context, pen testing complements the organization’s vulnerability management program and demonstrates to third parties that active security evaluations are being done to identify potential risks and impacts to the business.

Pen testing allows a third party to identify system vulnerabilities and threats. In turn, this evaluation helps organizations prioritize the most impactful security risks, and to design and implement controls to mitigate these risks.

Penetration testing is typically performed by external resources or specialized firms who bring not only technical experience and abilities, but also an objective assessment of any discovered vulnerabilities and their seriousness. It’s important for pen testers to be certified and to have relevant qualifications including experience.

Penetration tests are often conducted with vulnerability scans, but the techniques have different purposes. A vulnerability test is an automated process that looks for missing patches, misconfigurations, or other issues a hacker could exploit maliciously.

In contrast, a penetration test simulates a real-world attack on a system or network by humans who combine a variety of techniques to probe a system for vulnerabilities.

Along with regular vulnerability scans, penetration tests are good controls to help address vulnerabilities consistently. Sensiba typically recommends that organizations perform regular vulnerability scans monthly or, at maximum, quarterly, with pen testing occurring annually.

Penetration tests fall into three categories:

White box (also referred to as internal penetration testing): Penetration testers will have full access and detailed knowledge of the target systems or environments to identify vulnerabilities. The review will also include evaluations of the code and the internal structure of the organization’s software or applications. From a security evaluation perspective, this type of test typically yields the most findings for organizations to remediate.

Black box (also referred to as external penetration testing): Penetration testers will have no knowledge of the target systems or environments. The main goal of this approach is to simulate a real attack from an external threat. The tester probes the system and observes how the system reacts and performs under the test. Typically, this type of test yields the lowest findings.

Grey box: Blending white and black box techniques, penetration testers will have partial knowledge or access to target systems or environments. This type of test typically involves escalating their privileges, if possible, to systems. The tester typically knows the internal components of an application, but not how those components interact. This ensures that testing reflects the experiences of potential attackers and users.

Choosing the type of pen test depends on several factors, including the organization’s risk level, desired scope, and budget. Each the testing approach involves different access levels and systems knowledge, with white box testing being the most expensive, followed by grey box and black box.

Penetration testing is an essential component of enhancing your security controls and compliance with industry standards. We provide cost-effective pen testing services to help you improve your organization’s overall security posture. 

If you want to learn more about how penetration testing can benefit your organization, don’t hesitate to contact us.

A SOC 1 audit examines the internal controls over financial reporting (ICFR) a service provider has in place to ensure transaction processing or data manipulation on behalf of its customers is done consistently and reliably. A clean SOC 1 report provides assurance that transaction and data processing is performed consistently, and the information and can be relied upon by the service organization’s customers and their financial statement auditors.

Planning for an effective SOC 1 audit involves answering a series of questions:

Scoping conversations about your SOC 1 audit should take place early in the process and will typically involve your auditors. Often times, the scope of the SOC 1 can be determined by the purpose of the SOC 1, who is requesting the SOC 1, and what business functions they want coverage over.

An effective SOC 1 audit starts with the readiness phase. Before the audit, you’ll want to establish control objectives, identify the appropriate controls to meet those objectives, and draft control language. Ensuring your controls are best suited and assigned for the purpose of your software and planning for your auditors to walk through your processes, paves the way for a smooth and successful SOC 1 audit.

Most service organizations will have controls within several broad categories:

If a service organization has a completed SOC 2 audit, many of these controls can be mapped over to a SOC 1 report.

If your company only needs a SOC 1, it may make sense to obtain project management resources to work with the company on the core elements of a SOC 1 control environment, such as policies and procedures, entity-level controls, and other key details. Someone with SOC and controls experience can greatly benefit the company.

To learn more, our guide, Getting Your First SOC 1 Report, highlights the compelling benefits a SOC 1 report provides service organizations, and the value of leveraging a completed SOC 2 audit to launch a SOC 1 audit. 

When it comes to maintaining the integrity and trustworthiness of your organization’s information security practices, SOC 2 attestation is a critical component to help provide assurance to customers, their auditors, and potential business partners.

However, there are instances where the reporting period of a SOC 2 audit does not align perfectly with a company’s fiscal year or dating requirements of other stakeholders. This is where bridge letters come into play.

Before diving into bridge letters, let’s recap what SOC 2 is. SOC 2 (System and Organization Controls 2) is a type of audit report that evaluates an organization’s controls relevant to the AICPA’s Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.

Obtaining SOC 2 attestation is crucial for service organizations that handle sensitive customer data because doing so assures clients and stakeholders that the service organization maintains robust data security measures. Many customers, especially large enterprises, consider a clean SOC 2 report as a basic requirement as they evaluate potential service providers.

To gain a deeper understanding of SOC 2 reports and their components, please refer to our article, “Key Elements of a SOC 2 Report”.

A bridge letter, also known as a gap letter, is a document provided by a service organization (not the service auditor) to address the gap between the SOC 2 audit reporting period and the current date. The bridge letter provides interim (and unverified) assurance that the controls evaluated in the last SOC 2 audit report are still in place and operating effectively.

Bridge letters provide several benefits, including continuity of assurance. Clients and stakeholders rely on SOC 2 reports to assess the security posture of a service organization. A bridge letter ensures there is no gap in assurance between the end of the audit period and the next scheduled audit.

Bridge letters also help service organizations meet their Contractual obligations. Many contracts and regulatory requirements stipulate continuous compliance with internal controls. Bridge letters help organizations provide assurance they are meeting these obligations during the interim period.

They also support business continuity during situations such as mergers, acquisitions, or new business deals, where having an up-to-date assurance of SOC 2 compliance is crucial. A bridge letter provides the necessary assurance for participants to proceed with confidence.

A well-crafted bridge letter typically includes the following elements:

Service organizations issuing bridge letters should keep the following in mind:

Bridge letters play a crucial role in maintaining continuous assurance of a service organization’s SOC 2 control environment. They provide customers, stakeholders, and regulatory bodies with assurance the organization’s controls remain robust and effective between audit periods.

By understanding and using bridge letters effectively, service organizations can provide ongoing trust and compliance in their data security practices.

To learn more about SOC 2 audits and the role of bridge letters, get in touch with our team.

For service organizations that process transactions, manipulate data or store financial information on behalf of their customers, a SOC 1 (short for Service Organization Controls) report provides assurance that the processing of those transactions and data is done consistently and can be relied upon by your customer, and even more relevantly, your customer’s auditors.

A SOC 1 examination centers on the internal controls over financial reporting (ICFR) a service provider has in place to ensure transaction processing or data manipulation is done consistently and reliably. The SOC 1 standard is established and maintained by the American Institute of Certified Public Accountants (AICPA) and the examination is typically conducted by auditors from an independent accounting firm.

SOC 1 engagements require specialized auditor skills, including understanding the relevant standards as well as the business processes of their clients. The auditor provides an opinion upon completion of a SOC 1 engagement with the objective of a successful engagement offering a “clean” opinion that is attached to the SOC 1 report.

A SOC 1 report may be completed in one of two forms. A SOC 1 Type 1 report examines the service organization’s ICFR at a specific point in time and provides evidence on whether the controls are designed properly. A SOC 1 Type 1 report is usually done, if at all, on the initial SOC 1 engagement and as a precursor to the SOC 1 Type 2 report.

However, when your customer asks you for a SOC 1 report, they almost invariably mean a SOC 1 Type 2 report. The fundamental difference is that a SOC 1 Type 2 report tests those controls and their performance over a period such as six months or a year. As such, the SOC 1 Type 2 not only covers whether the controls are properly designed; the controls are also tested to determine if they are operating effectively over the relevant period. SOC 1 Type 2 engagements are by far the most common report, with most covering one year.

SOC 1 and SOC 2 reports have some overlap, but there are fundamental differences with SOC 1 vs. SOC 2.

A SOC 2 report reviews the controls that address the Trust Services Criteria (primarily security, but there are five criteria to choose from) and is relevant for service organizations that have custody of their customer’s data. The Trust Services Criteria provide a framework that can be applied to a wide range of service providers.

On the other hand, a SOC 1 report is focused on business processes specific to the service organization and thus there is significantly more variability because the control environment, and the related controls, will be specific to the service organization.

The testing procedures for a SOC 1 will focus on financial controls and transaction processing, while a SOC 2 will examine general IT controls (ITGC) testing and validation. This is where the overlap comes in. As most SOC 1 systems are built on information technology systems, many controls from a SOC 2 report can be mapped to a SOC 1 report.

Depending on the industry a service organization serves and its customer expectations, a provider may need to obtain both types of reports. If so, there can be efficiency and cost benefits to undergoing both types of audits at the same time.

Because a SOC 1 report is focused on financial reporting controls, it’s best suited for organizations that process or store financial data on behalf of their customers. Typical types of service organizations that may need a SOC 1 include:

Beyond these organizations, any company that processes or stores financial data for a customer may be asked for a SOC 1 report. Often the request for a SOC 1 report will be generated from your customer’s accounting and finance function, or you may get direct requests from a customer’s financial statement auditors (the intended reader of a SOC 1 report). For more information on who needs SOC 1 reports and why they matter watch the video below.

Obtaining independent verification that a service organization’s ICFR is performing effectively, known as a “clean” audit report, can provide several benefits such as:

Beyond compliance, a clean SOC 1 report can provide compelling benefits in attracting and retaining customers:

To learn more about SOC 1 reports and the benefits they can provide your service organization, contact us.

One of the most effective ways for Software as a Service (SaaS) companies to demonstrate the reliability, accuracy, and security of their services is by obtaining a SOC 1 report.

The Service Organization Controls (SOC) 1 report centers on the controls an outsourced service provider has in place to ensure the transactions or data processing that affect a customer’s financial reporting are completed accurately and reliably. A SOC 1 report focuses on processes and controls specific to the service organization and demonstrates that the provider uses industry-recognized best practices to assess and manage data accuracy risks.

The service organization’s customer is commonly known as a user entity, who typically uses a SOC 1 report’s findings during vendor selection and reviews. Additionally, a SOC 1 report is generally requested in financial reporting audits.

SaaS companies vary from email and CRM providers to companies offering accounting and ERP applications. The risk profile of the SaaS provider varies according to the applications they provide and the data they generate or process for their customers. SaaS platforms that affect their customers’ financial reporting (i.e., commission platforms, or sales and revenue platforms) need to reassure their customers and prospects that their data is accurate, and transactions are processed reliably.

The scope of a SOC 1 audit will include the SaaS provider’s internal controls over financial reporting (ICFRs) and its IT general controls (i.e., change management, logical access, system operations). The provider’s management will identify control objectives that address specific risks they wish to mitigate, as well as controls that are in place to support these control objectives.

Examples of ICFR-related controls for SaaS providers may include data input validation, record maintenance, and transaction reconciliations, or any other measure designed to ensure the validity of financial data and the provider’s security practices.

During the examination, the independent audit firm will review those objectives, test controls, and issue an opinion on the operating effectiveness of the controls that are in place.

Unlike a SOC 2 report, in which a service organization’s practices are compared against specific Trust Services Criteria, SOC 1 control objectives are flexible so providers can align with specific services affecting customer data and industry best practices.

In order to design SOC 1 control objectives effectively, SaaS providers need to focus on the features that effect their clients’ financials. Often times, this can be a daunting and overwhelming task that takes time and effort from the company. However, with the help of Sensiba and our SOC 1 readiness program, we provide consulting services for designing control objectives and identifying supporting controls.

For SaaS companies, a SOC 1 report can provide several benefits:

Providing a SOC 1 report is becoming a common contractual requirement as customers want assurance their financial data will be processed consistently and accurately.

To learn more about SOC 1 reporting for SaaS companies and how it can benefit you, contact us.

The ISO 27001 certification and the SOC 2 report are perhaps the leading frameworks for companies to demonstrate their commitments to securing customer data. Some service providers, depending on their customers and the types of information they handle, can benefit from obtaining both.  

Understanding the uses of each framework, where they overlap, their intended audiences—and whether an organization needs one, the other, or both—can play a large role in helping a service organization enhance its risk management efforts and highlight its security capabilities to current and prospective customers. 

A SOC 2 report provides service organizations with an external opinion on their compliance with a standardized set of industry-neutral controls based on the AICPA’s Trust Services Criteria—security, availability, processing integrity, confidentiality, and privacy.  

Under SOC 2, only the security criterion is mandatory. Deciding whether to include any of the other criteria depends on the types of information a service provider handles and its customers’ requirements.  

SOC 2 is not a certification. Instead, it is an audit opinion on the description of the system (a written narrative describing the infrastructure, data, people, processes, and boundaries of the system), and the controls implemented. 

An ISO 27001 Information Security Management System certification provides service organizations with a framework that’s more prescriptive than the SOC 2 criteria. ISO 27001 helps organizations manage and protect their information assets by developing policies, procedures, and controls to protect information from unauthorized access, alteration, theft, or destruction. 

An ISO certification requires a statement of applicability, risk assessment, internal audit, and management review. The certification also prescribes the number of days, primarily based on the organization’s headcount, an audit will require.  

A key difference between the two is that SOC 2 is not a certification. A SOC 2 report is an attestation by an independent audit firm as to whether the organization under review reasonably meets the standards outlined in the SOC 2 criteria.  

Both reviews look at the following:

ISO 27001 adds the following requirements:

SOC 2 adds the following:

The ISO certification is a three-year certification standard, starting with two stages in the first year. The stage one process is essentially a readiness review to ensure the organization has the information needed for the stage two audit. This will include, for example, items such as the organization’s internal audit function, risk assessment, and key policies and procedures.  

If this initial review identifies any areas of concern, the organization will typically have 30 to 60 days to remediate those issues. Once the areas of concern are addressed, the deeper-dive stage two audit will occur.  

After an organization receives ISO 27001 certification, surveillance audits are required for two years before its compliance needs to be recertified.  

ISO is an international standard, while SOC 2 focuses on North America. Service organizations supporting international customers outside of North America will benefit from an ISO certification.   

Similarly, companies based outside North America hoping to do business in the U.S., Canada, or Mexico will likely have an ISO certification but should consider obtaining a SOC 2 report to capture market opportunities in those markets.  

Service organizations operating globally would benefit from undergoing both audits. The good news is the types of information each review requires are similar enough that an organization undergoing one review will be about 70% of the way toward completing the other.  

Under the ISO 27001 standard, internal audits are required annually and must be conducted by someone who is both competent in auditing against the 27001 standard, as well as independent from the information security management system being reviewed.  

Because of these two requirements, most organizations interested in ISO certification outsource their internal audit function to a third party. For all but the largest organizations, someone on staff who is competent in the ISO standard is unlikely to be independent. In addition, outsourcing the internal audit function often results in a more thorough evaluation of their management system.  

Organizations interested in pursuing ISO 27001 and SOC 2 reviews can streamline the process by scheduling both examinations carefully. For instance, SOC 2’s higher sampling requirement means the information gathered for that audit can also be used as part of the ISO certification, if the audits are timed correctly.   

Similarly, the organization should align the periods when auditors will be reviewing evidence with less-busy times of the fiscal year. Conducting both reviews at once can reduce the administrative overhead on their internal teams.   

Service organizations that process personal health information and need to demonstrate compliance with Health Insurance Portability and Accountability Act (HIPAA) security and privacy safeguards can also incorporate that examination with a SOC 2 audit.  

To learn more about ISO 27001, SOC 2, and the potential benefits of undergoing both reviews, contact us.