Guest post by Nathan Sykes. Nathan is the founder of Finding an Outlet, a site dedicated to B2B IT news and trends.
SaaS companies live in a regulated market even when they do not think of themselves as regulated companies. A subscription product can create tax obligations in dozens of jurisdictions, carry customer data across borders, trigger customer audit requirements, and expose the provider to privacy, security, accessibility, and sector-specific rules.
The practical question is whether the company can prove what it is doing. Strong SaaS compliance means knowing which obligations apply, assigning owners, keeping policies current, running the workflows behind those policies, and preserving the evidence that customers, auditors, tax authorities, and regulators may ask to see.
Cloud-based solutions, remote technologies, and cloud service providers are more prevalent than ever. As IT governance standards become more stringent, customers become more aware of the requirements set upon them and ask providers to help with audits, documentation, and assurances. The pressure often gets offloaded onto SaaS providers, who may not have built their early operating model around legal constraints, financial limitations, tax requirements, or regulatory requirements outside their own direct responsibilities.
That landscape is changing rapidly. Audits, data governance, security protections, privacy rights, customer obligations, and additional regulatory constraints now sit right alongside product delivery. SaaS companies need to know what is changing in the legal landscape and how it affects day-to-day operations.
Sales tax and nexus
For SaaS teams, sales tax is often the first regulatory surprise. The 2018 Supreme Court decision in South Dakota v. Wayfair confirmed that states can require out-of-state sellers to collect sales tax when they meet an economic nexus threshold. Today, the Sales Tax Institute tracks economic nexus requirements across every state with a sales tax.
That does not mean every SaaS subscription is taxed the same way. States differ on whether they tax electronically delivered software, digital services, implementation fees, support, bundled packages, marketplace transactions, and exempt customers. A SaaS company can also create nexus through employees, contractors, events, reseller activity, or other in-state presence.
Nexus is essentially the influence or presence that allows a state to require a business to collect and pay sales tax. The old physical-presence model is not enough for SaaS and e-commerce retailers because economic nexus can apply even where a provider lacks offices, employees, or data facilities in the state. Determining nexus has always been tricky because each state varies regarding qualifications, and what gives you nexus in one state may be completely different in another.
How nexus applies
A useful SaaS tax workflow usually starts with five questions:
- Where are customers located, and which address should drive the tax decision?
- Which states tax the exact product, subscription, add-on, or service being sold?
- Which economic nexus thresholds have been crossed, and when?
- Which exemptions, resale certificates, marketplace rules, and billing-system rules apply?
- Where is the evidence kept for registration decisions, filings, exemptions, and tax-engine configuration?
The risk is not only under-collection. Over-collection can damage customer trust and create refund work. A common complication is that low transaction thresholds can develop nexus faster than expected when a subscription-based pricing model creates multiple invoices per client. Work with an accountant, experienced professional, or tax advisor to identify where sales tax is necessary, where exemptions apply, and how taxing and monetary collection policies should be documented.
Do not overlook this if the business is spread across varying locations or service coverage is far-reaching. Failure to understand state-by-state obligations can lead to severe consequences, including fines, compounding interest, court costs, refund work, and customer disputes. Treat sales tax as an owned operating process, not a once-a-year accounting lookup.
Provider-focused auditing
SaaS buyers increasingly ask vendors to prove their controls before a contract is signed and again during renewal. The request may be called vendor due diligence, third-party risk management, procurement review, security review, or a compliance audit, but the operating need is the same: customers want evidence that the provider can protect their data and keep critical services running.
Security and data governance audits are less an optional state of checks and balances and more a legal, contractual, and regulatory requirement in many SaaS buying processes. The onus has shifted to providers to help deal with and prepare for some of these experiences before any legal audit takes place.
A policy page is rarely enough. Enterprise clients increasingly require records on IT security audits, clear-cut data storage, handling and protection policies, performance standards, risk management, disaster recovery plans, and evidence that the provider actually follows the process it describes.
Common auditing concerns
- Security policies, access reviews, and administrative privilege controls.
- A dedicated security team or named owner to handle events, failures, security violations, and data breach reporting.
- Penetration testing or third-party testing history, including the last relevant test, the results, and remediation work.
- Application and software update procedures, including how maintenance affects security, customer downtime, and scheduled maintenance announcements.
- Encryption, key management, logging, monitoring, and alert response.
- Backup schedules, restore tests, recovery objectives, and business continuity plans.
- Incident response ownership, notification paths, and post-incident review.
- Subprocessor governance, data location, and customer-facing data processing terms.
- API authentication, rate limits, change management, and release approvals.
- Retention, deletion, export, and customer offboarding processes.
- Physical security for data facilities or operations sites where applicable.
- Documentation for HIPAA, Sarbanes-Oxley, PCI DSS, and other similar-level regulations when they apply.
More than proper planning and documentation, it helps to establish these elements long before clients ask, so that when the time comes the company can provide the necessary assurances. The same evidence base also helps identify and remediate vulnerabilities discovered through external means or internal discovery.
Process Street helps teams run these compliance operations as living work. The platform combines governed Docs for policies and procedures, Ops for recurring workflows and evidence collection, and built-in AI to help teams monitor gaps and keep work moving inside one Compliance Operations Platform.
Legally mandated data protections
Data protection rules have become part of the default SaaS operating environment. The EU GDPR remains one of the most visible examples, but privacy obligations now come from many sources: national rules, U.S. state privacy laws, sector-specific laws, contractual data-processing terms, customer security addenda, and cross-border transfer requirements. The European Commission maintains its EU data protection legal framework as the authoritative starting point for GDPR materials.
For SaaS providers, the work usually turns into operational controls: mapping what personal data is collected, defining controller and processor roles, honoring data subject requests, managing subprocessors, retaining data only as long as needed, deleting or exporting data on request, and handling incidents quickly. GDPR Article 33, for example, requires notification to the supervisory authority within 72 hours when a notifiable personal data breach is discovered.
GDPR is designed to protect privacy and personal data for people in the European Union, but SaaS providers outside Europe can still be affected. The protections may extend to customers, a customer’s customers, and sometimes beyond direct clientele. That means even if a company does not serve affected customers directly, one of its clients or service users may create obligations where applicable.
Data protection also requires precision about purpose, nature, storage duration, responsibilities, rights, and requirements. If a provider says data will be kept for two years, the retention process should honor that period. If a customer can download, see, or delete personal data associated with them, the operational workflow needs to support that promise. Customers should be informed through the right channels when a breach or security issue requires notification, and providers must ensure protections are in place to prevent data breaches and fully secure customer information.
Process Street also maintains a public GDPR statement for customers reviewing its privacy posture. The same principle applies to any SaaS company: make the public promise clear, then build internal workflows that can prove the promise is true.
General data practices
Regulatory compliance depends on everyday data hygiene. A company can have the right policy and still fail if backups are untested, access reviews are informal, source code changes skip review, or sensitive customer data is copied into tools where it does not belong.
Outside of the legal and regulatory space, there is also the matter of protecting internal data and digital assets. Many auditing and data protection strategies focus on external data channels that stem from customers and umbrella users, but the business has proprietary data, trade secrets, source code, operational records, and security materials that also need to be handled properly.
Start with the controls that support every framework: identity and access management, least privilege, audit logs, backup and restore testing, retention schedules, secure development practices, vulnerability management, and a clear escalation path for incidents. Process Street publishes more detail on its own approach to security, but each SaaS provider needs operating evidence that matches its product, risk profile, and customer commitments.
Teams should be asking operational questions on a schedule: How often is sensitive data backed up and where is it stored? How often are backups completed and restore-tested? If there is a data breach, failure, or complication, what could be lost? What security measures retain control of systems and networks? How will service interruptions affect customers, their data, and their users?
Good data practices are also practical. They reduce duplicate work during customer reviews, shorten audit cycles, make incidents easier to handle, and help teams avoid last-minute scrambles when a customer asks for proof. Protecting customer and client data is vital, but the content that relates to the business, organization, primary operations, and continued operations needs the same discipline.
The landscape is tumultuous; be ready to evolve
Compliance requirements keep moving. State privacy laws continue to expand in the U.S. The EU AI Act entered into force in 2024 and becomes broadly applicable in 2026, with some provisions on different timelines. NIST released Cybersecurity Framework 2.0 in 2024, and public companies face SEC cybersecurity disclosure rules for material incidents. In some sectors, FTC Safeguards Rule updates and breach-notification requirements add another layer of operating discipline.
This is evident through many discussions about cloud computing and SaaS. The enterprise market has a general focus on network and user security, data protection, customer rights, moral responsibility, product obligations, and service offerings. Regulations can extend beyond direct clientele and stretch further down the chain to include anyone affected by internal data usage and collection.
The answer is not to chase every rule manually. SaaS companies need a compliance operating system: a register of obligations, mapped controls, named owners, review cadences, approval workflows, evidence folders, escalation rules, and a way to update the system when regulations, products, vendors, or customer promises change.
Compliance internally is crucial to the success and continued operations of the business. The last thing a provider needs is to deal with repercussions handed down by government bodies, customers, or the community at large because preventable obligations were missed.
That is what turns regulatory compliance from a set of scattered documents into a repeatable business capability. The companies that handle it well do not wait for an audit to discover what is missing; they keep the proof close to the work all year.