What a software company owes its customers

A business selling software as a service (SaaS) does not need a single licence to operate. What it needs is a set of documents that each answer to a specific law or a specific customer expectation. Missing one rarely stops a sale on day one; it stops the sale when a customer's procurement or security team asks for it, or it becomes the thing a regulator points at after a complaint.

An uptime commitment (SLA) is the one common document Falrow does not publish yet. During a private beta, promising an uptime figure we cannot yet measure would be dishonest. It will arrive with general availability.

Privacy law gives different jobs to the party that decides why personal data is used (the controller, or "business" in California) and the party that handles it on someone else's behalf (the processor, or "service provider"). A SaaS company is both, for different data:

• For the content customers put in the product, such as tickets, client records and meeting notes, the customer is the controller and the software company is its processor. The customer decides what goes in; the provider may use it only to run the service. That relationship is what the DPA governs.
• For its own website visitors, sign-up forms, user accounts, security logs and invoices, the software company is the controller. That is what its Privacy Policy covers.

Getting this split right matters. A provider that uses customer content for its own purposes, for example to train a model or to market to the people in it, stops being a processor for that use and takes on all of a controller's duties, usually without a legal basis to do so. That is why our Terms and DPA say plainly that we do neither.

The EU General Data Protection Regulation applies to a company outside the EU when it offers services to people in the EU (Article 3(2)). A US software company with European customers, or even European users inside a US customer's workspace, is in scope. The UK has a near-identical UK GDPR, and Switzerland its own FADP.

What it requires of a SaaS provider, in practice:

• A legal basis for each use of personal data. For a business tool these are mostly contract and legitimate interests, not consent.
• Transparency (Art. 13–14): a privacy notice that says what, why, how long, who receives it, transfers, and rights.
• Processor contracts (Art. 28) with the content the law lists: instructions, confidentiality, security, subprocessor rules, assistance, deletion, audits.
• Security appropriate to the risk (Art. 32), and breach notification to the authority within 72 hours, and to affected people when the risk is high (Art. 33–34). A processor must tell its customer without undue delay so the customer can meet that 72-hour clock.
• Records of processing (Art. 30), and impact assessments for high-risk processing (Art. 35).
• Data subject rights: access, correction, deletion, portability, objection, generally within one month.
• A representative in the EU (Art. 27) for non-EU companies, unless processing is only occasional and low risk.

Fines reach €20 million or 4% of worldwide annual turnover, whichever is higher, for the most serious breaches, and €10 million or 2% for breaches of processor and security duties.

Personal data may leave the EU only to a country the European Commission has found adequate, or with safeguards. The United States has a partial adequacy decision, the EU-US Data Privacy Framework, which covers only US companies that self-certify to it. Everyone else uses the Standard Contractual Clauses (SCCs): a fixed text the Commission adopted in 2021, which the parties may not change but must complete with annexes describing the transfer, the security measures and the subprocessors.

The UK uses an addendum to the same clauses (the IDTA Addendum), and Switzerland accepts the SCCs with small adaptations. Exporters must also assess whether the destination country's laws, especially on government access, would undermine the clauses, and add measures where needed.

How Falrow handles it: workspace data is hosted in the EU, so most processing never leaves it. Where data does reach the US (AI requests, email delivery, support access), our DPA incorporates the SCCs, the UK Addendum and the Swiss terms, so a customer needs no separate signature.

There is no general federal privacy law in the United States. Instead:

• California's CCPA (as amended by the CPRA) applies to for-profit businesses that do business in California and meet one threshold: annual revenue above about US$26.6 million (adjusted for inflation every two years), buying, selling or sharing the data of 100,000 or more California residents or households, or earning half their revenue from selling or sharing personal information. It gives residents rights to know, delete, correct and opt out, and it reaches business contacts and employees, not only consumers.
• About twenty other states, including Virginia, Colorado, Connecticut, Texas, Oregon and New Jersey, have comprehensive privacy laws with similar rights and thresholds based mostly on the number of residents whose data is processed. Delaware's own Personal Data Privacy Act took effect on 1 January 2025 and applies at 35,000 Delaware residents.
• Service provider contracts. Even when a software company is below the thresholds, its customers often are not, and the law requires them to have specific contract terms with their vendors. California's regulations list ten. A SaaS company that cannot offer these terms loses those customers. Our DPA includes all of them.
• The FTC Act. The Federal Trade Commission treats a broken privacy or security promise as a deceptive practice. That is the strongest reason to say only what is true in a privacy policy, and to keep it current.
• Breach notification. All fifty states require notice to affected residents after a breach of certain personal data, with deadlines that range from "without unreasonable delay" to 30 days.
• Children. COPPA applies to services directed at children under 13. Business software should say it is not for children, and mean it.

Spring Digital Commerce LLC is currently below the CCPA and Delaware thresholds. We follow the same rules anyway: our customers need us to, and it is cheaper to build it in from the start than to retrofit it.

The AI Act regulates AI systems by risk, and like the GDPR it applies to non-EU companies whose AI systems are used in the EU. It is arriving in stages:

Provider or deployer? The company that builds an AI system and puts it on the market is its provider; the business that uses it is a deployer. A SaaS company that builds AI features into its product is the provider of those features. A customer that uses them, for example to write summaries it sends to its own clients, is a deployer, with its own (lighter) duties.

Where Falrow sits. Its AI features help plan software work: they are not in any high-risk category, use no prohibited practice, and interact with people inside a business tool. The duties that apply are AI literacy and Article 50 transparency, which we meet by labelling AI-detected requests, marking agent changes by the door they came through, and requiring a person to act on AI proposals before they become work. The AI & Agent Terms set this out.

Fines reach €35 million or 7% of worldwide turnover for prohibited practices and €15 million or 3% for most other breaches.

Since 12 September 2025, Chapter VI of the EU Data Act requires providers of "data processing services", which includes SaaS, to remove obstacles to customers switching to another provider or to their own infrastructure. It applies to non-EU providers with EU customers, and it overrides contract terms that say otherwise.

• The contract must let the customer switch at any time with no more than two months' notice, followed by a transition of up to 30 days (extendable once by the customer) during which the service continues.
• It must list exhaustively which data can be exported and which internal data is excluded, give at least 30 days to retrieve data afterwards, and guarantee erasure once the switch is done.
• The provider must publish its export formats and interfaces, offer open interfaces free of charge, and tell customers where its infrastructure is and how it protects data against unlawful government access (Art. 28 and 32).
• Switching charges may cover only direct costs until 12 January 2027, and are prohibited from then on.

In practice this ends long lock-in contracts for EU customers. Our Switching & Data Export page is the published information the Act requires, and our Terms give every customer, not only EU ones, the right to leave on those terms.

The DSA regulates "intermediary services", which includes hosting services that store content at a user's request. A SaaS product that stores customer content is a hosting service in the legal sense, even when nothing is public. Since 17 February 2024 every hosting service with EU users must:

• name a single point of contact for authorities and for users (Art. 11–12);
• if it has no EU establishment, appoint a legal representative in the EU (Art. 13);
• describe in its terms any restrictions on content and how they are enforced (Art. 14);
• offer a notice-and-action mechanism for reporting illegal content (Art. 16); and
• give a statement of reasons when it restricts a user's content or account (Art. 17).

The heavier duties, such as transparency reports and complaint systems, apply to online platforms that disseminate content to the public, and small companies are exempt from most of them. Falrow's Legal Notices and Acceptable Use Policy cover the duties above.

European law requires consent before a site stores or reads anything on a visitor's device, unless it is strictly necessary for the service the visitor asked for. A sign-in cookie or a dark-mode setting is exempt. Analytics, advertising pixels and most embeds are not. Courts have also found that simply loading a font from Google's servers discloses the visitor's IP address to a third party without a legal basis (Munich Regional Court, January 2022).

The simplest compliant design is the one Falrow uses: no non-essential storage at all, and fonts served from our own domain. No banner is needed because there is nothing to consent to.

No single law prescribes a software company's security controls, but many require "appropriate" or "reasonable" security and then judge it after an incident: GDPR Article 32, California's reasonable-security statute (Civ. Code § 1798.81.5), New York's SHIELD Act and the FTC's enforcement practice. Enterprise customers translate the same expectation into questionnaires and, later, requests for SOC 2 or ISO 27001 reports.

Two EU laws often come up and mostly do not apply to a small SaaS company. NIS2 covers medium and large entities in listed sectors. The Cyber Resilience Act covers products with digital elements, such as installable software and connected devices; pure SaaS is outside it unless it is the remote processing component of such a product.

What matters most in practice: encrypt in transit and at rest, control and log access, keep backups you have actually restored, have an incident plan, and notify customers fast enough that they can meet their own 72-hour GDPR deadline. Our commitments are on the Security page.

• Accessibility. The European Accessibility Act (from 28 June 2025) covers consumer-facing services such as e-commerce and banking; business-to-business software is largely outside it, and microenterprises are exempt. In the US, websites are regularly the subject of lawsuits under the Americans with Disabilities Act. Building to WCAG 2.2 AA is the practical standard either way.
• Business customers only. Selling only to businesses keeps a SaaS company outside most consumer protection law: the EU 14-day withdrawal right, consumer auto-renewal statutes and unfair-terms rules for consumer contracts. That only holds if the terms and the sign-up flow make clear the service is for business use.
• Copyright. To rely on the DMCA safe harbour, a US provider must designate an agent with the US Copyright Office (renewed every three years) and act on valid notices.
• Export controls and sanctions. US law restricts providing services to sanctioned countries and listed persons. Terms should prohibit it and sign-up should not knowingly allow it.
• Marketing email. CAN-SPAM governs commercial email in the US (an opt-out and a postal address in every message); in the EU and UK, marketing email to individuals generally needs consent. Transactional email, such as invitations and security notices, is exempt from both.
• Taxes. US states tax SaaS differently, and remote sellers can owe sales tax once they pass a state's economic nexus threshold. EU VAT on business-to-business services is usually handled by reverse charge.
• Recording calls. Many US states, including California, require every participant's consent to record a conversation. A product that imports call recordings or transcripts should make its customers responsible for that consent, and remind them of it.

For the data you put into Falrow, you are the controller. These are the things the law expects of you that Falrow cannot do for you:

• Tell your team that Falrow is used, including that Slack messages in connected channels are read to find requests, and link them to our Privacy Policy for their account data.
• Get recording consent before importing meeting recordings or notetaker transcripts, where the law requires it.
• Check your client contracts allow you to use service providers like us for their information, and list Falrow among your own subprocessors if you have such a list.
• Keep out data Falrow is not built for: health data, payment card numbers, government ID numbers and other special categories.
• Review AI output before it becomes a commitment, and disclose AI-written text where Article 50 of the AI Act requires it of you as a deployer.
• Manage access: remove people who leave, give agents the narrowest scope that works, and revoke connections you no longer use.