Satisfying consumer demand, increasing employee engagement and retention, and meeting stronger regulatory expectations are among the compelling benefits organizations can achieve by integrating environmental, social, and governance (ESG) considerations into their strategies and operations.

Speaking during a Sensiba webinar, Carrie Mayo, founder and CEO of marketing services firm MAYO Web + Marketing, and Eric Hudson, founder and CEO of environmentally friendly consumer products company Preserve, said the benefits of ESG initiatives far outweigh the time and financial investments.

“There is absolutely a growing trend of consumers buying sustainable products who are willing to pay more for them, Mayo said. “Consumers are willing to embrace the brands that are choosing purpose and sustainability.”

Hudson’s company has focused on creating environmentally focused products since its founding in 1997. He said his company’s fastest-growing product is the POPi 5 shave system, which features a handle manufactured with plastic diverted from oceans.

“We work with nonprofits that are pulling waste plastic out of waters that’s bound for the ocean,” Hudson said. “That plastic comes to us and gets ground into material that can make a razor handle. We also give 25% of our proceeds to nonprofits that are working to make a difference for ocean health.”

He also cited a program with Boston University’s cafeteria to replace single-use cups and cutlery with implements that can be returned to the cafeteria for reuse.

“[The school] has saved a lot of money by reducing waste and expense, and reducing the purchase of single-use products,” Hudson said. “They’re seeing incredible financial merits of choosing a more environmentally friendly system.”

Similarly, Mayo said her firm factors environmental considerations into its purchases, such as sourcing promotional merchandise locally or using products that incorporate recycled materials.

A demonstrated commitment to ESG efforts can also help companies with their employee recruitment, retention, and engagement efforts.

“People want to work for companies that align with their values,” Mayo said. “The way we do this is giving our employees the power to choose how we donate our money, how we donate our services, or where we spend our volunteering time.”

“Our ESG initiatives…have led to people being attracted to working at Preserve,” Hudson said. “We have very low turnover, and we have a highly engaged and motivated team. The initiatives that we have engaged in really help our organization and our employees understand what we do on an ESG front, and they love that aspect of Preserve.”

Beyond employees, Mayo said sharing an authentic ESG story can increase an organization’s attractiveness to a wide range of stakeholders.

“From a brand and marketing perspective, it is critical right now to incorporate [ESG] into your value proposition sooner rather than later. Do it authentically, and it is far deeper than a tagline or a page that’s hidden somewhere on your website,” Mayo said.

Karen Burns, leader of Sensiba’s ESG and Sustainability practice, shared a variety of regulatory mandates and explained how standards are converging to harmonize sustainability reporting. These include disclosure laws in California, climate disclosure rules in Europe, and climate reporting requirements proposed by the U.S. Securities and Exchange Commission.

Hudson said his company factors regulatory considerations into his company’s products and materials decisions.

“It’s going to be happening more, but we already have concrete examples of where regulation in a number of states is affecting Preserve and our offerings,” Hudson said. “There are regulations that require recycled content, or that limit the use of single-use products, and that demand the recyclability of a product or the compostability of a product. Our products, because we’ve been focused on sustainability, comply. We’ve been ahead of the curve.”

To learn more about incorporating ESG in your business strategy and operations, contact us.

Every business knows the importance of good record keeping, but just how long do you need to hold onto certain documents? Maintaining adequate records of your business transactions is important for not only tax purposes, but also to serve as a safeguard against unexpected litigation down the road. Here’s an overview of proper record retention. 

While this list provides general recommended record retention periods, certain circumstances may vary. If you have questions about your particular situation, contact our tax experts. 

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.

The Cloud Security Alliance (CSA) is a trusted authority on modern cloud security. For organizations managing enterprise customer demands and navigating compliance questionnaires, CSA’s STAR program offers a path toward greater efficiency and credibility.

The CSA is widely recognized for its Consensus Assessments Initiative Questionnaire (CAIQ), a tool designed to reduce the burden of responding to dozens of different security questionnaires. However, while the CAIQ brought much-needed structure, many enterprises still rely on their frameworks and requirements when assessing vendors.

To streamline and strengthen third-party due diligence, CSA created the Security, Trust, Assurance, and Risk (STAR) program. This tiered certification and attestation framework validates cloud security practices through independent review. For cloud-first organizations, CSA STAR can help meet enterprise expectations and eliminate redundant questionnaires.

At the heart of the CSA STAR program is the Cloud Controls Matrix (CCM), a comprehensive set of security requirements covering modern cloud risks such as virtualization, API security, and data portability. Organizations that meet these requirements can be listed in CSA’s public registry, helping to reduce the need for bespoke customer audits.

There are two levels of participation:

Level 1: Self-Assessment
Organizations document how their internal controls meet CCM objectives and submit this to CSA for review and public posting. While useful, this level is rarely sufficient on its own to meet enterprise due diligence standards.

Level 2: Third-Party Attestation or Certification
This level involves a formal review by an independent audit or certification body. A successful assessment results in a published Level 2 status in the CSA registry, which many enterprise customers accept as a substitute for lengthy security reviews.

CSA STAR Level 2 can be achieved through certification or attestation, depending on your business’s needs and audit preferences.

Both paths are equally recognized by CSA and listed identically in the registry. The choice largely comes down to whether you’re working with a certification body, an assurance firm, or both (in the case of dual-qualified providers).

CSA STAR is gaining traction as a modern, cloud-specific alternative to traditional frameworks. While standards like SOC 2 and ISO/IEC 27001 remain common, many enterprises now treat them as minimum requirements—especially as automated compliance platforms have made these certifications more accessible, sometimes at the expense of rigor.

CSA STAR goes deeper. It addresses the evolving landscape of cloud risks, including device management, human behavior, and data governance. As a result, it’s increasingly preferred by enterprises evaluating medium- to high-risk vendors.

We’ve observed significant growth in CSA STAR adoption. Just a few years ago, it was rarely mentioned. Today, it’s a standard consideration in vendor conversations, particularly for those looking to demonstrate stronger cloud security practices.

Implementing CSA STAR doesn’t mean starting from scratch. You can often build on existing certifications such as ISO/IEC 27001 or pair it with a SOC 2 audit using a combined SOC 2 + CSA STAR attestation approach. This method offers flexibility and efficiency, particularly when aligned with frameworks like GDPR or HIPAA.

At Sensiba, our readiness platform supports CSA STAR alongside 11 other standards, allowing you to reduce duplication and simplify cross-framework compliance. Whether you’re looking to meet enterprise client requirements or elevate your overall security posture, CSA STAR can be a powerful addition to your strategy.

Ready to explore CSA STAR certification or attestation? Contact us to discuss your options or start a readiness assessment tailored to your goals.

Co-authored by: Jessica Mendiola

A financial statement review provides an independent examination of your company’s financial records. Unlike a formal audit, which involves extensive testing and other procedures, a review relies on analytical procedures and inquiries.

A review is designed to provide reasonable assurance that the company’s financial statements are presented fairly and accurately, are free from material misstatements, and comply with the applicable accounting standards.

Key stakeholders such as investors, lenders, bonding companies, and regulatory agencies often require a financial review to ensure transparency and accountability. Beyond compliance, financial statement reviews offer businesses an opportunity to identify potential issues early, enhance risk management, and demonstrate financial credibility to external parties.

The review process involves several key participants, including:

Accurate and up-to-date financial records are essential for a successful financial review. Accurate records form the foundation of any review and provide a clear picture of your company’s financial health. Without accurate records, you (and your stakeholders) risk drawing incorrect conclusions that can lead to poor business decisions.

The key steps to take before a review include:

Some of the key financial documents you’ll need to provide:

Organize these documents in a logical order, either by category or date, and ensure they are easily accessible. Digital storage solutions, such as cloud-based systems, can simplify this process by enabling quick retrieval and secure storage. Keeping records organized speeds up the review and demonstrates your commitment to transparency and efficiency.

During a financial review, you can expect questions about your financial statements, business practices, and overall financial health. Being well-prepared for these questions can be invaluable in instilling confidence in your review engagement team.

Consider the following common questions:

Prepare clear and concise answers to potential questions and be ready to provide documentation or context for any unusual items or trends in your financial statements. Transparent communication can help build trust and minimize follow-up questions or concerns. Likewise, being open about your company’s financial health allows reviewers to offer more meaningful feedback and recommendations.

While a financial review may seem daunting at first, proper preparation and a clear understanding of the process can turn it into an opportunity to enhance your business’s credibility, identify areas for improvement, and make more informed decisions. By following these guidelines, you will be well-equipped to navigate the review process with confidence and clarity.

To learn more about the benefits of financial reviews, contact us.

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.

Increasing the frequency of SOX audits is a strategic move that helps companies enhance the robustness of their internal controls, improve financial reporting accuracy, and ensure ongoing compliance with regulatory requirements.

Companies typically conduct interim and year-end SOX testing as part of their audit plan, but relying solely on interim and year-end SOX testing may result in limited visibility, delayed issue identification, increased risk exposure, complacency, inadequate response to change, and regulatory scrutiny. 

To mitigate these diverse risks, organizations should complement periodic testing with continuous monitoring and auditing practices to ensure ongoing compliance, enhance control effectiveness, and address emerging risks and issues promptly.

Increasing the frequency of SOX audits can provide several benefits:

Frequent audits allow for the early detection of compliance issues and internal control weaknesses. By identifying problems as they arise, companies can implement corrective actions promptly and reduce the risk of financial misstatements and regulatory penalties.

Increased audit frequency can streamline operations by embedding compliance into daily business processes. This integration fosters a culture of continuous improvement, where compliance becomes a routine part of the organizational workflow rather than a periodic checkpoint.

To fully realize the benefits of more frequent SOX audits, organizations must implement a structured approach that incorporates technology, risk assessment, collaboration, and continuous education.

Here are some essential strategies for increasing the frequency of SOX audits effectively:

Utilize automation and advanced data analytics to facilitate continuous auditing. These tools can monitor transactions and controls in real-time, providing immediate insights and reducing the burden of manual audit tasks.

Focus on high-risk areas that have the greatest potential impact on financial reporting. By prioritizing these areas, companies can allocate resources more effectively and ensure critical risks are identified and addressed promptly.

Foster collaboration between internal audit, compliance, and financial reporting teams. Regular communication and information sharing can help identify and address issues more efficiently, ensuring that all stakeholders are aligned on the organization’s compliance objectives.

Invest in ongoing training for audit and compliance personnel. Keeping staff updated on the latest regulatory changes, auditing techniques, and technological advancements is essential for maintaining an effective continuous auditing program.

Increasing the frequency of SOX auditing offers numerous benefits, from timely issue detection to enhanced operational efficiency. By adopting a more frequent audit schedule, leveraging technology, and focusing on high-risk areas, organizations can strengthen their compliance posture and build a robust framework for financial integrity.

As the business environment continues to evolve, embracing continuous and frequent SOX auditing will be key to staying ahead of the curve and ensuring long-term success. Contact us to explore ways to enhance your internal control program and reduce year-end SOX audit pressures.

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. 

In this part of our change management blog series, we look at the change review and approval process. These are essential parts of development in the constantly changing Software as a Service (SaaS) industry, ensuring the effects of any changes are considered on the platform’s functionality, user experience, security posture, and compliance with standards such as SOC 2. This connects innovation with operational reliability and accountability.

Before exploring the change review and approval procedure, it helps to understand the SOC 2 compliance context. SOC 2, created by the American Institute of CPAs (AICPA), addresses five criteria topics: security (where change management generally sits), availability, confidentiality, processing integrity, and privacy of customer information. SOC 2 compliance is not just a badge of honor for SaaS companies, but also a fundamental component of reliability and security.

Justification of changes

Change proposals or requests usually include a description of the change, the impact, required resources, and the intended outcome or benefit of the change. This stage is essential in clarifying the key points of the suggested feature or modification and laying the groundwork for a thorough assessment. Technical specifications, acceptance criteria, potential customer impact, and impact assessments should be covered in detail. This is especially important when considering the processes and controls required for SOC 2 compliance.

Impact assessment

It is critical to conduct a detailed impact assessment that evaluates the impact the change could have on the organization’s system and its users. The results of the assessment should be used to influence the extent and type of change testing and approval required, any mitigating technical or operational controls required, and communication required internally and externally. 

Change review

A collaborative review based on the type of change and the expected impact, including stakeholders from operations, security, development, and compliance, can ensure the right stakeholder buy-in, awareness, and planning, and increase the likelihood of a successful change design and implementation. The broader the impact or complexity of a change, the more consultation and review may be required with the relevant stakeholders.

Change approval

It’s crucial to establish precise criteria for approving changes. To align with the SOC 2 criteria requirements, changes to data, software, infrastructure, and supporting procedures should be approved prior to implementation. This approval may include stakeholders from the development, security, compliance and/or operational parts of the organization, based on the predetermined criteria (e.g., impact and nature of the change).

This can also involve specifying who has the final approval in the process, typically someone other than the change developer, and making sure they have access to the key data when making their final approval decision. 

Change documentation

For reference and compliance, it is essential to record each stage of the change management process, including development requirements, review, approval, and testing requirements, as well as the rationale for any key decisions during the process. This documentation, which shows due diligence, is a key part of SOC 2 compliance. Technical documentation such as logs in a version control system and audit trails can also be a key reference.

For SaaS companies navigating the change review and approval process with an emphasis on SOC 2 compliance, a comprehensive change management process can be a challenging but crucial step. It is foundational in ensuring that enhancements and developments are safe, compliant, in line with company objectives and technically sound.

When carried out successfully, this can build user and stakeholder trust and reaffirm the SaaS company’s dedication to security, dependability, and ongoing compliance.

To learn more about SOC 2 compliance and change management, contact us.

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.

When pursuing SOC reporting, businesses often ask whether to start with a Type 1 or go straight to a Type 2. Both SOC 1 and SOC 2 frameworks offer two report types:

All businesses are looking for the most cost-effective approach. Why spend more than what’s necessary, particularly when it comes to a “compliance” activity? Many businesses see it as a “tick-the-box” where the costs, in terms of external fees and internal time investment, are best minimized.

The industry standard approach to SOC reporting is to first issue a Type 1 report to confirm the design of your control practices, followed by a Type 2 report to confirm the ongoing operating effectiveness. Most customers or end users expect the Type 2 reports to be provided on an annual basis to confirm ongoing effectiveness with continuous coverage.

The first Type 2 period usually starts from the day after the Type 1 report date. But the SOC reporting approach, dates and period(s) are flexible for the business to decide. This should be informed by the end users’ expectations and requirements.

An organization may consider skipping Type 1, but following the path from Type 1 to Type 2 provides the following advantages:

It may seem counterintuitive, but skipping the Type 1 report can cost more over time.

Consider this simplified example:

Client Y incurs more costs—plus a readiness assessment, typically over $10,000, is often needed before launching a Type 2 without a Type 1 foundation.

Type 1 reports provide a controlled environment to identify and resolve issues before the clock starts on your Type 2 reporting period.

Going straight to a Type 2 can leave you exposed. Without a Type 1, you may face gaps in documentation or audit evidence. While a readiness review can help, it’s not a substitute for a full audit and often lacks the rigor needed to instill confidence

Type 1 reports can be issued much sooner—often 3 to 6 months earlier than Type 2. Since Type 2 requires a full reporting period to pass before testing can begin, it naturally takes longer to produce.

If your customers or sales prospects request a SOC report soon, issuing a Type 1 early can satisfy their needs and keep deals moving.

The first audit always takes the most effort. Starting with a Type 1 spreads out that lift.

Type 1 audits focus on testing the design of controls, requiring fewer samples and less testing than Type 2. This gives your team time to get comfortable with the process before scaling up to a full operational audit.

Many first-time Type 2 reports cover only 3–6 months. That limited window often results in “disclosures of non-occurrence,” such as:

These aren’t audit findings, but they can reduce the perceived assurance of your report.

Starting with a Type 1 allows you to demonstrate control design upfront, then follow with a full 12-month Type 2 that shows consistent operation—without gaps.

Controls that pass a Type 1 may later need refinement in a Type 2, where auditors test for operational effectiveness. Starting with Type 1 gives you time to:

This staged approach supports maturity over time, rather than expecting perfection from day one.

We typically recommend clients start with a SOC Type 1 report before moving to Type 2. It’s a strategic way to manage costs, reduce audit friction, and build compliance readiness with confidence. That said, some organizations may still opt to go straight to Type 2 based on urgency or specific customer demands—and that’s fine, too.

Want help determining the best approach for your SOC reporting journey? Contact us. We’re here to help you get it right the first time—and add value beyond the audit.

The SOC 2 Plus CDR approach to accreditation requires a few adjustments to the standard SOC 2 reporting method, but the benefits often outweigh the effort.

The Consumer Data Right (CDR) is a regulatory framework that allows service providers to access consumer data collected by banks, with other industries expected to follow. To participate, organizations must earn CDR accreditation, which includes submitting an assurance report verified by an independent chartered accountancy firm. These reports must align with Service Organization Control (SOC) standards.

SOC reports can be confusing due to the range of international acronyms, such as ASAE/ISAE 3150/3402, SSAE 16/18, ATC-105, and ATC-205. In the U.S., they’re broadly categorized as SOC 1 (focused on financial reporting controls) and SOC 2 (focused on trust principles like security, confidentiality, availability, processing integrity, and privacy).

For CDR purposes, a SOC report can be used if it adequately demonstrates compliance with the requirements listed in CDR Schedule 2. That’s where SOC 2 Plus CDR comes in.

A CDR assurance report is essentially a tailored SOC 2 report. In some areas, CDR requirements are more prescriptive than SOC 2 while in others, less so. The flexibility of the SOC 2 framework allows us to adjust accordingly.

Here are five key ways we tailor the SOC 2 report to meet CDR expectations:

We use software to automatically map your controls across SOC 2 and CDR Schedule 2. This eliminates redundant work and ensures your report shows clearly how you meet the relevant criteria. We include a mapping table in Section V of your SOC 2 report so the Australian Competition and Consumer Commission (ACCC) can easily see how Schedule 2, Parts 1 and 2, are addressed.

SOC 2 does not prescribe specific controls like multifactor authentication (MFA), software whitelisting, or incident response, though many reports include them. CDR Schedule 2, Part 2, does prescribe these controls. To meet CDR expectations, we ensure your control descriptions reflect these higher, defined requirements.

Schedule 2, Part 1, includes governance, security capabilities, and incident response, but provides limited detail. SOC 2, however, offers well-established guidance in these areas. We lean on these common practices to meet and document the Part 1 requirements.

SOC 2 requires a clear system description, including infrastructure, software, data, people, and processes. To align with CDR, we ensure your report defines the scope of the CDR data environment specifically, either as the entire system or as a clearly delineated subset of a broader environment. Our updated templates help you frame this appropriately.

SOC 2 traditionally allows a “carve-out” for third-party providers, but in practice, we take a “carve-in” approach—verifying their controls where they impact your environment. This is straightforward for major cloud providers that already have SOC 2 reports. For vendors without assurance reports, additional verification may be needed, especially if they handle critical infrastructure such as physical data centers.

Compared to a CDR-specific ASAE 3150 report, SOC 2 Plus CDR offers multiple advantages. It aligns your organization with an internationally recognized assurance framework while providing cost and efficiency benefits. Because SOC 2 is widely adopted, many of its required controls and reporting elements are already in place at most organizations—making this a more scalable and strategic approach.

To explore whether SOC 2 Plus CDR is the right fit for your CDR accreditation journey, contact us. We’d be happy to help.

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.

BlackLine’s Transaction Matching tools provide a nearly seamless way for finance teams to reconcile suspense accounts, enhancing operational efficiency and accuracy while reducing the time and effort involved in this important process.

As with other types of transactions, BlackLine automatically reviews suspense account transactions as they come in overnight. The tool matches and reconciles transactions that meet the finance team’s rules and tolerances before flagging exceptions that need further attention. This automation allows the finance team to spend a few minutes focusing on analyzing unmatched items, rather than hours manually reconciling accounts.

BlackLine ensures data quality through automated data extraction, standardization, and cleansing processes. This helps in maintaining consistent and accurate data, which is essential for effective reconciliation of suspense accounts. The tool’s ability to understand complex data relationships and apply business rules ensures transactions are matched accurately and exceptions are flagged for review.

Of the many types of accounts BlackLine can help finance teams reconcile automatically, overnight suspense account matching is one of the most common areas where organizations can benefit.

BlackLine provides real-time monitoring and reporting capabilities, enabling organizations to track the reconciliation process and identify any issues promptly. This feature is crucial for maintaining the accuracy and timeliness of financial reporting.

High-volume general ledger accounts, such as payroll clearing accounts, often have numerous transactions flowing through them and reconciling those accounts manually can be a daunting task. BlackLine’s Transaction Matching tool is designed to handle these volumes effortlessly by clearing transactions automatically based on predefined logic, significantly reducing the manual workload.

Finance teams can set matching tolerances to allow transactions within a specified date range or amounts to be reconciled automatically. This feature is particularly useful in scenarios where transactions do not align perfectly but still fall within acceptable limits. As a result, the tool can clear many transactions without human intervention, ensuring that only genuine exceptions need to be reviewed manually.

For example, a finance team trying to close out the organization’s books for May can easily identify transactions that cleared in early June and segregate them for further reconciliation on the June books.

For payroll clearing accounts, required adjustments such as an employee whose pay is being garnished for alimony, child support, or a similar mandatory deduction can be identified and reconciled. BlackLine allows the finance team to book the appropriate entry and provide supporting comments and documentation about the adjustment, who recorded it, and the underlying reasons.

BlackLine enhances financial reconciliation accuracy by minimizing human error. The tool’s predefined logic ensures only transactions meeting specific criteria are matched, leaving little room for mistakes. BlackLine also provides a clear audit trail, documenting every transaction to improve.

Similarly, BlackLine enhances internal controls by providing a comprehensive audit trail and supporting regulatory compliance. Every transaction is documented, which improves compliance and transparency while reducing the risk of errors and fraud.

Overall, automating the reconciliation process frees up the finance team to focus on higher-value tasks. Instead of spending hours matching transactions manually, accountants can spend time analyzing exceptions and providing valuable insights by collaborating with business unit leaders.

If you’re interested in learning more about how BlackLine can transform your reconciliation processes, reach out to the BlackLine practice at Sensiba. We can help you leverage the power of automation to enhance your financial operations.

Staying ahead of the competition is a challenging and often expensive task. While many economic incentives are targeted at a particular industry or even a specific company, the Research and Development (R&D) tax credit helps level the playing field and incentivizes business growth in the United States. As a general business credit, it provides valuable cash savings, enabling reinvestment and growth.

The federal R&D tax credit, also known as the Research and Experimentation (R&E) credit, provides up to approximately 10% of project-qualifying expenditures. To determine if a research project (or portion of a project) is eligible for inclusion in the credit R&D credit, the business component (the R&D credit phrase for “project”) and associated activities must satisfy the R&D tax credit four-part test.

Research must be undertaken for a Permitted Purpose, which includes a new or improved product or process function, performance, reliability, or quality. Specifically excluded are efforts related purely to aesthetics or taste.

There must be Technological Uncertainty related to the capability, methodology, or design of the business component. This requirement excludes economic uncertainty and other uncertainties related to market acceptance or performance.

The project or activity must be Technological in Nature. The business component must rely on a hard science such as engineering, physical or biological sciences, or computer science. A qualified business component cannot be based on soft sciences such as arts, humanities, social science, or psychology.

A Process of Experimentation must be used to resolve the uncertainty. The taxpayer must demonstrate how business components progress from initial concept through design, testing, and validation to commercialization and also how the technological uncertainty is mitigated throughout this process.

When a project is determined to meet the above four criteria, the associated expenses for that project can be quantified and used to generate an R&D tax credit. Qualified research expenses consist of the following three basic expense categories:

Wages include the eligible portion of all taxable compensation and are typically the major driver of R&D credits. Qualified wages are the portion of an employee’s compensation corresponding to the percentage of working time engaged in one of the following designations:

Supplies are the materials used to evaluate and test designs throughout the development process. Eligible supplies include items used in prototype builds, business component performance evaluations, and engineering software licenses.

Contract Research is outside vendor expenses paid to individuals or other businesses on behalf of the company engaging in qualified research. Generally, if the service performed would be considered an in-house qualified wage expense, the amount is includable. Any contract research expenses are included at 65% and must occur in the United States.

The AMT restriction frustrated many taxpayers who could not offset tax with the R&D credits their businesses were generating. The PATH Act allowed eligible small businesses (ESB) to offset tax liability below their AMT amount. An ESB is defined as a corporation that is not publicly traded, a partnership, or a sole proprietorship with average annual gross receipts not exceeding $50 million for any of the three taxable years preceding the current taxable year.

One major flaw with incentivizing R&D investment through a tax credit is that a business must have taxable income to offset to benefit. This meant many high-tech startups and young companies could not use the R&D credit. This changed with the PATH Act, as now Qualified Small Businesses (QSBs) can use the R&D tax credit to offset the FICA portion of the employer payroll tax.

A QSB is defined as a business with less than $5 million in annual gross receipts and has no gross receipts for more than five years. The maximum payroll tax offset per year is $500,000 and can be generated in up to five tax years. This valuable enhancement to the R&D tax credit enables startups to keep up to $1.25 million at work during a critical phase in a company’s lifecycle.

The R&D tax credit is a complicated intersection of Congressional intent, IRS regulations, and tax court rulings. The process, while complex, can be navigated efficiently and effectively with the right help. Our R&D credit experts are here to provide direction and help you create a plan to use this credit to help build your business. Contact us to get started.