Trust, Security and Regulation

When anyone can ship a product in a week, buyers start asking a different question: can I rely on this company? You can no longer postpone security and compliance until a large customer forces the issue. Handled early and simply, they give customers a reason to choose you over a faster but shakier competitor.

Trust Is a Competitive Advantage

Every customer who signs up takes a risk. They hand you their data, their workflow and sometimes their reputation with their own customers, and the more your product matters to their work, the larger that risk feels.

Most young companies treat trust as a cost. Treat it as part of the product instead. A clear security page, a straight answer to "where is my data stored?" and a founder who can explain how access is controlled all shorten sales cycles. Larger buyers often run a security review before they sign, because a breach can cost them far more than a missing feature. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, a record high.

Your customers' risk includes you. In Verizon's 2026 Data Breach Investigations Report (DBIR), breaches involving a third party reached 48% of all breaches, up 60% in a year. The US Cybersecurity and Infrastructure Security Agency (CISA) says products should offer multi-factor authentication, logging and single sign-on at no extra cost. A small company that does this from day one stands out.

Trust also takes years to build and one incident to lose. A leaked database or a careless email can undo a lot of goodwill, and the habits in this chapter cost little now and a great deal to retrofit later.

Security Basics for a Small Team

You do not need a security team to be reasonably secure. You need a short list of habits, applied consistently from the first day.

• Turn on multi-factor authentication everywhere: email, code hosting, cloud accounts, domain registrar, payment provider and password manager. CISA's guidance is that any MFA is better than no MFA, and that phishing-resistant MFA, meaning FIDO/WebAuthn passkeys or hardware keys, is the standard to aim for. Stolen credentials and phishing started 13% and 16% of breaches respectively in the 2026 DBIR. In 2024, attackers stole data from Snowflake customer accounts using passwords harvested by infostealer malware; Mandiant found the impacted accounts were not configured with MFA, and about 165 organisations were notified they might be exposed.
• Apply least privilege. Give each person and each service only the access it needs, separate production from development, and remove access on the day someone leaves, contractors included.
• Manage secrets properly. Keep API keys and database credentials out of your code and out of chat. Use your hosting platform's environment variables or a dedicated secrets manager, and rotate any key that has been exposed.
• Test your backups. An automated backup you have never restored from is a guess. Do a practice restore so you know how long it takes and what breaks.
• Keep dependencies updated. Most of your code is other people's open-source packages. In the 2026 DBIR, exploiting vulnerabilities became the most common way into a breach, at 31%, overtaking stolen credentials for the first time in the report's 19 years, and the median time to fully fix a critical known-exploited flaw was 43 days. Turn on automated vulnerability alerts and update on a schedule, so you are not patching everything at once in a panic.
• Log what matters. Record sign-ins, permission changes and access to sensitive data, and store those logs where an attacker with access to your app cannot quietly delete them. When something goes wrong, the logs tell you what happened.

For a fuller map later, NIST's Cybersecurity Framework 2.0 has quick-start guides for small businesses.

AI coding tools make it easy to ship code you have not fully read. Review anything that touches authentication, payments or personal data yourself. Watch what goes into AI tools too: the 2026 DBIR found source code was the most common data type sent to unapproved AI services. Agree which tools your team may use, and keep customer data and secrets out of any whose data handling you have not checked.

Privacy by Design

Privacy by design means thinking about personal data when you design a feature, before a customer or regulator asks. GDPR writes this into law as "data protection by design and by default" (Article 25). The most useful principle is data minimisation: collect only what you need, keep it only as long as you need it, and limit who can see it. GDPR requires personal data to be "limited to what is necessary" for its purpose (Article 5).

Data you never collected cannot leak. Before you add a field to a signup form or log a request body, ask what you will actually do with it. If the honest answer is "it might be useful someday," leave it out.

A few habits help:

• Keep a simple list of the personal data you hold, where it lives and why.
• Write a privacy policy in plain language that matches what you actually do.
• Know which third-party services receive your users' data, including analytics and AI providers.
• Make it easy for a user to export or delete their data.

The Regimes You Will Meet

Most founders run into the same handful of frameworks. In outline:

Framework	What it is	When it tends to matter
GDPR	EU data protection law	You process personal data of people in the EU, even if your company is elsewhere
CCPA / CPRA	California privacy law, as amended	You do business with California residents and meet the law's thresholds
SOC 2	An attestation report against AICPA criteria, not a law	Enterprise customers ask for it during procurement
EU AI Act	Risk-based EU regulation of AI systems	You build or deploy AI systems used in the EU

GDPR sets rules on the lawful basis for processing personal data, transparency, security, and individual rights such as access and deletion. It can apply to companies outside the EU that offer goods or services to people in the EU or monitor their behaviour there (Article 3), so the location of your servers does not settle the question. It expects you to report a personal data breach to the regulator, where feasible, within 72 hours of becoming aware of it (Article 33). The most serious infringements can bring fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher (Article 83).

The CCPA, as amended by the CPRA, gives California residents rights over their personal information, including the rights to know, delete, correct and opt out of its sale or sharing. According to the California Attorney General, it applies to for-profit businesses that meet any one of three thresholds, based on revenue, the number of California residents whose data they handle, or the share of revenue that comes from selling personal information. Other US states have passed their own privacy laws, so check where your users are.

SOC 2 is an independent report, performed by a CPA firm, on controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy, using criteria from the AICPA. No law requires it, but many larger buyers expect one. The security basics above cover much of the groundwork, and starting them early makes an eventual audit far less painful.

The EU AI Act entered into force on 1 August 2024. It sorts AI systems by risk. Practices such as social scoring are prohibited. High-risk uses, such as CV-sorting for recruitment or credit scoring, carry significant requirements. Systems such as chatbots carry transparency duties, like telling users they are dealing with a machine, and minimal-risk uses such as spam filters carry no new rules. According to the European Commission, the timeline has been phased:

• Prohibitions and AI literacy duties applied from 2 February 2025.
• Obligations for general-purpose AI models applied from 2 August 2025.
• Most of the Act became applicable on 2 August 2026.
• After a 2026 amendment known as the AI Omnibus, rules for high-risk systems in areas such as hiring and credit apply from 2 December 2027, and for high-risk AI built into regulated products from 2 August 2028.

These dates have already moved once, so check the Commission's page for the current position. If your product makes decisions about people, in hiring, credit or education for example, look closely at where it falls.

This chapter is general information, not legal advice. Laws change, and how they apply depends on your facts. Before you handle sensitive data, sell into regulated industries or expand into a new market, talk to a qualified lawyer.

When Onchain Adds Value

Treat Web3 components as a tool. They earn their place when they solve a problem that ordinary databases and payment rails handle poorly, for example:

• You need a shared record that several parties who do not fully trust each other can verify without relying on one operator.
• Payments need to be programmable, such as releasing funds when conditions are met or splitting revenue automatically among many parties.
• Stablecoins let your customers settle cross-border payments faster or more cheaply than the alternatives available to them.

They mostly add risk when the blockchain is there for marketing, when a token has no clear job, or when users must manage keys they do not understand. Smart contracts are hard to change once deployed, and a bug can mean real, irreversible losses, so they need careful review. Key management matters as much. Chainalysis counted over $3.4 billion in crypto theft in 2025, and its analysis highlights attacks on private keys and signing processes, including tricking legitimate signers into approving malicious transactions. In February 2025, attackers took about $1.5 billion from the exchange Bybit, a theft the FBI attributed to North Korea. Tokens and stablecoins can also raise securities, money transmission and other regulatory questions that vary by country. If a normal database would do the job, use a normal database. At AW3 we build onchain components only where they make the product better for the customer.