When handling sensitive health data, HIPAA compliance isn’t optional—it’s legally required. For startups entering the healthcare space or SaaS companies expanding into health tech, understanding the requirements of the Health Insurance Portability and Accountability Act (HIPAA) is essential to reducing risk and building trust.

HIPAA is a U.S. federal law enacted in 1996 to safeguard Protected Health Information (PHI). It sets strict requirements for how PHI must be accessed, stored, and shared, and it applies to healthcare providers, insurers, and any vendors or “business associates” that process PHI on their behalf.

For early-stage companies, HIPAA compliance can seem overwhelming. Limited resources and competing priorities often make it difficult to know where to start. The key is to focus on a few foundational elements:

By focusing on these areas, startups can build a scalable compliance foundation without stalling innovation.

For SaaS providers handling PHI, HIPAA should be a central part of your security and infrastructure strategy. This includes ensuring your application architecture, hosting environment, and data storage align with HIPAA’s technical safeguards.

Working with a HIPAA-compliant cloud provider is a good start, but it’s not enough. Your team is still responsible for ensuring the software you build includes essential features like encrypted communications, user access controls, audit logging, and breach notification processes.

Technically, software can be built to support HIPAA compliance, but software alone isn’t compliant. True HIPAA readiness involves a combination of secure technology, documented policies, employee training, and consistent enforcement. Even the most secure platform can become a liability if people or processes fail.

Automation can dramatically reduce the complexity of managing HIPAA compliance. Tools that streamline risk assessments, policy management, training, and documentation can reduce manual error and scale with your company’s growth.

For SaaS companies, integrating compliance checks directly into the software development lifecycle is a practical way to maintain HIPAA standards as new features are released.

There is no official “HIPAA certification.” Instead, companies may undergo independent audits or assessments to evaluate their compliance posture. These audits don’t result in a government-issued certificate, but they can serve as critical proof of due diligence to clients, partners, and investors.

HIPAA compliance is a significant responsibility, but it’s manageable with the right systems and guidance. By focusing on key requirements, leveraging automation, and embedding compliance into your operations, you can protect sensitive data while supporting business growth.

Whether you’re a health tech startup or an established SaaS company expanding into healthcare, proactive HIPAA compliance reduces risk and builds credibility with your customers.

Need help assessing your HIPAA readiness or preparing for an audit? Contact us to explore how we can support your compliance journey.

As Artificial intelligence (AI) introduces new organizational opportunities and risks, the ISO/IEC 42001 standard offers guidance and controls to help organizations deploy AI efficiently and mitigate the related security risks by developing an Artificial Intelligence Management System (AIMS).

ISO/IEC 42001, published in 2023, addresses the AI system lifecycle from initial concepts to final system deployment and operations. The standard is designed to help organizations manage the risks associated with AI and ensure their systems are developed and used responsibly.

ISO/IEC 42001 compliance should be considered by any organization with public-facing products or services leveraging AI.

To evaluate compliance with the standard, an ISO/IEC 42001 certification audit will examine several areas, including AI-specific ethical, security, and operational considerations, system lifecycle management, performance optimization, and documentation.

Organizations should also evaluate the various organizational roles within the AI lifecycle—production, development, provision, and use—to understand and manage risk effectively.

ISO/IEC 42001 places significant emphasis on AI risk and impact assessments. For the standard’s mandatory risk assessment, organizations are required to identify potential risks related to AI systems, evaluate those risks, and develop risk mitigation plans.

The standard’s AI Impact Assessment process involves:

Organizations are required to document this process and measure AI-related risks and their potential consequences.

The ISO/IEC 42001 standard follows a similar structure as ISO/IEC 27001 (Information Security Management System), making it easier for organizations to integrate their security and compliance efforts. Thanks to this similarity, and the overlap in the information evaluated during a certification audit, organizations that have ISO/IEC 27001 certification can be well on their way to obtaining ISO/IEC 42001 certification if they choose to.

The ISO/IEC 42001 standard consists of 10 main clauses:

The first three clauses are shared with other standards, and specific considerations are addressed in Clauses 4-10:

ISO/IEC 42001 also includes two annexes that are important to an organization’s certification efforts and provide additional guidance and information:

These annexes offer detailed guidance on AI management ranging from development to risk assessment and sector-specific applications.

Achieving ISO/IEC 42001 certification can provide several benefits for organizations that include:

Like other notable security frameworks, ISO/IEC 42001 certification demonstrates an organization’s commitment to data protection and responsible policies and procedures.

An ISO/IEC 42001 certification audit is a comprehensive process that involves multiple stages to evaluate an organization’s AIMS. 

The stage one audit includes:

The stage two audit is more in-depth and involves

After the audit, organizations must address any identified non-conformities and provide evidence of corrective actions before receiving a decision from the certification body.

Once certified, organizations must undergo annual surveillance audits to maintain certification and participate in a recertification audit every three years.

As a certification body, Sensiba conducts audits against a variety of standards including ISO/IEC 42001, ISO/IEC 27001, ISO/IEC 27701, and others. To learn more, contact us.

Bring-your-own-device (BYOD) policies are common among startups and fast-growing businesses. They can reduce hardware costs, minimize redundancy, and offer employees more flexibility. But from a security and compliance perspective, BYOD introduces unique challenges, especially when external standards apply.

Frameworks like SOC 2 tend to offer more flexibility around endpoint device controls. However, standards such as ISO/IEC 27001, CSA STAR, and especially the Consumer Data Right (CDR) come with more prescriptive requirements that may be harder to meet under a BYOD model. 

The central challenge with BYOD is that the devices used to access sensitive systems and data are employee-owned. This raises questions about how much control an organization can or should exercise. For example:

Employees’ personal preferences often conflict with corporate security needs. At the same time, endpoints are increasingly in focus across compliance frameworks because they’re a common point of data leakage.

In most organizations, people—not systems—represent the greatest risk. Endpoint devices are where data can escape secure cloud environments and where oversight is weakest.

SOC 2 generally takes a risk-based approach. If your environment is low-risk and your data resides primarily in secure cloud platforms, an acceptable use policy signed by employees may be sufficient.

ISO/IEC 27001 and CSA STAR offer more structure. However, they allow organizations to reduce or exclude certain controls if they can show the associated risk is effectively managed or not applicable.

CDR, however, sets a higher bar. The standard includes several defined control objectives focused specifically on endpoint device management within the CDR Data Environment. That makes endpoint oversight a key area of concern for data recipients.

One of the most practical ways to manage BYOD risk and reduce your compliance burden is to narrow the scope of in-scope devices. This is particularly important for frameworks like CDR, which define boundaries around a specific environment.

For example, your engineering, security, and operations teams may be required to use company-issued devices or follow stricter security policies if using their own. By mapping the systems in your CDR environment and limiting access to only necessary personnel, you reduce the number of devices that fall within scope.

Fewer devices in scope means fewer compliance obligations and a clearer path to accreditation.

In rare cases, removing endpoints from scope is possible—but only if you can prove those devices pose no material information security risk.

That doesn’t just mean devices don’t store sensitive data. It means they can’t store it.

You’ll need to demonstrate that employees are technically unable to export or save sensitive data to their personal devices. This requires strong access controls, data segregation, and enforcement mechanisms. You must be able to detect or prevent unauthorized activity and show that the risk is remote enough to be acceptable under your chosen framework.

For example, if production database access is tightly restricted, controlled through temporary credentials, and supported by independent approval processes, that risk can be reduced to an acceptable level. However, scoping out endpoints becomes much more difficult if sensitive data is stored in shared folders like Dropbox or Google Drive.

Here’s a checklist, roughly in order of expectation and the breadth of standards that require or generally cover them:

To learn about effective endpoint management, contact us.

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.

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.

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.

An important step in an emerging technology company’s growth is choosing the right accounting and financial management platform for its current and future needs.

Relying on a basic accounting program designed for small businesses can hinder an emerging company’s growth. Basic tools require manual work that diverts attention and fail to provide insights that help the company’s management understand the factors driving its financial and operational performance.

Shifting to accounting software like Sage Intacct can help technology companies get a better handle on their revenue and increase their ability to recognize revenue properly under ASC 606, Revenue From Contracts with Customers.

The primary benefits of an industry-focused accounting software to growing technology companies include:

If a technology company is seeking latter-stage funding, or considering a public offering, it will need to provide detailed metrics to potential investors about its current performance and expected growth rates. Failing to do so will likely disqualify a company from attracting sophisticated investors.

Industry-focused accounting software can also help technology companies comply more easily with the revenue recognition requirements of ASC 606.

For instance, SaaS companies typically have revenue from a variety of sources within a given customer contract. These often include the underlying software, with revenue that must be recognized over the life of the agreement, but also related services such as training, maintenance, and technical support. Trying to allocate these elements monthly using spreadsheets can be challenging and often frustrating, but they can be tracked automatically in Sage Intacct.

Similarly, cloud software contracts with usage-based billing can be difficult to monitor manually, often resulting in billing and revenue-tracking errors.

Manual revenue calculations also hinder the ability of technology companies to develop more than a basic understanding of their financial performance. They may be having more success, for instance, in reaching customers within specific industry verticals or company sizes. However, they won’t be able to quantify that success if they’re wasting time reconciling data listed in separate spreadsheet files.

An industry-focused accounting platform enables management to analyze revenue trends and develop forecasts based on data, rather than intuition and optimism. Being able to understand and trust their financial and operational data enables technology companies to improve efficiency and better align management strategy with their business development efforts.

As an emerging tech company, it’s critical to take control of finances and streamline your accounting processes. Don’t let the burden of manual bookkeeping and reporting hold you back. By selecting the right accounting software, you can automate your financial tasks, ensure accurate record-keeping, and gain valuable insights into your company’s financial health.

Selecting the right software for you can be challenging. Contact us to learn more about how Sage Intacct can help your technology company understand its performance and opportunities.

Technology companies often operate at a loss, especially in their early stages, as they work to develop their product or service and grow their revenue. When this is the case, the company’s auditor will likely place a heavy emphasis on evaluating the company’s going concern disclosures.

To remain a going concern, a company must have the resources to continue its operations for the foreseeable future. Financial statements are generally prepared using the assumption that a business will continue to be a going concern.

Management is required to assess whether there are existing conditions that raise substantial doubt about the company’s ability to continue as a going concern. If substantial doubt exists, management must evaluate its plans (and the effectiveness of those plans) to alleviate this risk. This assessment will then be evaluated by the company’s external auditor.

The going concern assessment should be based on whether it is likely the company will not be able to fulfill its obligations within one year of the date the financial statements were issued.

Under U.S. accounting standards, certain disclosures are required if any conditions give rise to substantial doubt about the company’s ability to continue as a going concern. The disclosures should include:

If management’s plans do not alleviate the substantial doubt, the disclosures must also include a statement that there is substantial doubt about the company’s ability to continue as a going concern. In this circumstance, the audit report will also include an emphasis on the matter paragraph regarding the existence of substantial doubt.

A company’s auditor will be required to obtain appropriate evidence to evaluate management’s assessment regarding its ability to remain a going concern. To obtain this evidence, an auditor will likely request the following information from management:

If your business needs assistance regarding your going concern disclosures or assessment, contact us. Our auditors can help you understand how the assessment will affect your financial statement disclosures.

ASC 842 lease accounting is effective for calendar year-end entities for the 2022 fiscal year. The core concept of ASC 842 is the intention of the FASB to move previously off-balance-sheet operating leases to the balance sheet to better reflect the contractual liabilities owed under these arrangements.

Many venture-backed early-stage startup companies, or remote-enabled companies, have minimal or no operating leases. However, this does not mean ASC 842 concepts and provisions do not need to be considered.

The company doesn’t have any leases as of year-end, so there is no ASC 842 impact.

Truth:

This is a misconception because ASC 842 is required to be adopted as of the beginning of the period presented. Any leases outstanding as of 1/1/22 for calendar year-end entities would need to be included in the analysis of adoption and calculation of adoption entries.

The company has no operating leases and never has, so there is no ASC 842 impact.

Truth:

While the absence of traditional operating leases for office space or equipment results in no impact of adoption related to those types of leases, ASC 842 requires entities to evaluate whether there are embedded leases that were not considered under prior guidance. The FASB Master Glossary defines a lease as:

“A contract, or part of a contract, that conveys the right to control the use of identified property, plant, or equipment (an identified asset) for a period of time in exchange for consideration.”

Many companies that do not have office leases may still have embedded leases with service providers that may need to be accounted for. In many cases, agreements with cloud providers for designated servers or server space (data centers and colocations) qualify as embedded leases and require capitalization.

Related-party leases are evaluated the same way under ASC 842 as old lease accounting standards.

Truth:

ASC 842 requires that leases entered into with parties related to the company that are under common control are required to be assessed based on the written contract terms, regardless of the intent of the terms.

A related-party lease whereby either party may terminate the contract for convenience with no significant penalty would not have commercial substance and would not be a lease under ASC 842 as the terms are not enforceable over the specified terms. This is a change from prior guidance whereby related-party leases were evaluated for their economic substance above the legally enforceable terms and conditions.

ASC 842 impacts the balance sheet only and has no other significant effects after adoption.

Truth:

Companies should be diligent in considering the impact of adoption to reporting to external parties, especially banks that require financial covenant compliance, and plan proactively to inform stakeholders of any anticipated impact. Impacts on accounting and disclosure of deferred taxes should also be considered.

Companies should also ensure policies and procedures are put into place to account for new leases and contracts and any lease modifications as they occur.

Make sure to review all lease agreements, amendments, and related documents carefully and keep any changes in writing. Related-party leases should also be evaluated to ensure the contract terms in the executed lease properly reflect the intended use. 

These are just some of the many nuances in applying ASC 842 completely and accurately to ensure GAAP compliance for technology and startup companies. If you have questions, contact our team to understand the impact on your company.