Security and Data Protection Policy

Yemoko holds businesses' books, payroll and payment records, so we protect it in layers: each company's data is walled off from every other, sensitive fields are encrypted, and card and bank credentials never reach us at all.

At a glance

A request must pass five layers, outermost first:

1. Encrypted connection. HTTPS for every request; the database accepts only encrypted, authenticated connections.
2. Verified sign-in. Verified email, bcrypt-hashed password, optional two-factor sign-in (required for platform administrators) and limits on repeated attempts.
3. Role and permission check. Every API request is checked on the server for membership, role and permission.
4. Company wall in the database. Row-level security: a query only ever sees the user's own company, even if application code makes a mistake.
5. Encrypted at rest, sensitive fields twice. AES-256 storage, plus AES-256-GCM for SSNs, tax IDs, two-factor secrets and bank tokens.

Card numbers, mobile-money PINs and bank passwords never enter Yemoko at all: Stripe, Flutterwave, CinetPay and Plaid hold them.

The database wall (layer 4) is the one that matters most: even a mistake in Yemoko's own code cannot show one company's records to another.

1. Infrastructure and hosting

• Application: runs on Vercel in the United States (Portland, Oregon). The app servers hold no customer data between requests.
• Database and files: Supabase's managed PostgreSQL and file storage, on Amazon Web Services in Oregon, USA.
• Physical security: the data centers are operated by AWS and Vercel's providers, with their own physical-access controls and independent audits. Yemoko runs no servers of its own.
• Network: all traffic to yemoko.com uses HTTPS. The database accepts only encrypted connections that carry valid credentials.

2. Separation between companies

Every record in Yemoko belongs to one company. The database itself enforces that a user can read or change only records of companies they belong to (PostgreSQL row-level security). This holds even if the application code had a bug.

• Every API request is checked on the server for the user's membership, role and permission in the company it targets.
• Database functions that run with elevated rights check membership themselves, and cannot be called by anonymous visitors.
• Automated tests try to read and change another company's data through both the database and the API, and must be refused. The current suite has 62 security checks and 127 cross-company checks.
• Suspended or cancelled companies are blocked from their data except for paying or resubscribing.

3. Encryption

Encryption keys are held in the hosting provider's encrypted environment settings, separate from the database and the source code.

4. Sign-in and access control

For your users

• Email verification before an account can be used.
• Optional two-factor sign-in with an authenticator app, with one-time recovery codes.
• Limits on repeated sign-in and password-reset attempts.
• Six roles inside each company (owner, admin, manager, accountant, employee, viewer), each limited to what it needs. Only the owner controls the subscription.
• Password re-confirmation before destructive actions, such as downgrading, cancelling or deleting a company.

For Yemoko staff

• Production access is limited to the people who operate the service.
• Every administrator account on our hosting, database, payment and code providers is protected by two-factor authentication.
• Credentials and keys are kept in encrypted environment settings, never in source code.
• Staff do not access a customer's data except to provide support the customer asked for, to investigate a security issue, or when the law requires.

5. Payment and banking data

Yemoko never sees or stores full card numbers, mobile-money PINs or bank passwords.

• Cards: entered on Stripe's hosted checkout or in Stripe's secure fields; Stripe is certified PCI DSS Level 1.
• Mobile money and African card payments: completed with Flutterwave or CinetPay, on their pages or apps.
• Bank connections: you sign in to your bank in Plaid's or Stripe's window. Yemoko receives only an encrypted access token, account names with masked numbers, balances and transactions.
• Payouts go from the payment provider to your own merchant account. Yemoko never holds your funds.

6. Application security, testing and change management

• Security checks on every change. Every change is automatically type-checked, built and run through the security test suite, and production is deployed only after all of these pass: a change that fails any check never reaches yemoko.com. Changes to data access are also run through the cross-company isolation tests before release.
• End-to-end tests. They exercise the live service: sign-up, invoicing, payments, plan changes and cancellation, using throwaway test companies that are deleted afterwards.
• Input safety. All database queries are parameterized. Requests that change data require same-site origin checks (protection against cross-site request forgery).
• Secrets. API keys for providers are stored only as encrypted environment variables and rotated if exposure is suspected.
• Webhooks. Notifications from Stripe and other providers are accepted only with a valid signature, and each is processed once.
• Dependencies. Third-party libraries are kept up to date, and security advisories for them are acted on.

7. Logging, monitoring and business continuity

• Audit log. Sensitive actions (sign-ins, permission changes, plan changes, deletions, payments) are logged with user, time and IP address. Company owners can request an extract of their company's log from support@yemoko.com.
• Error logs. Application errors are logged by the hosting provider and reviewed.
• Redundancy. The hosting and database providers run on infrastructure designed to survive the failure of individual servers.
• Your own copies. You can export your records, receipts, employee data and pay stubs at any time from Settings. We recommend keeping regular exports of records you are legally required to keep.

8. Incident response and breach notification

1. Detect and contain. We revoke exposed credentials, block the cause and preserve evidence.
2. Assess. We work out what data and which companies are affected.
3. Notify. We tell affected customers without undue delay, and within 72 hours of becoming aware of a personal data breach. We say what happened, what data is involved, what we have done and what they should do.
4. Help. We help customers meet their own duties to notify regulators and individuals.
5. Learn. We fix the root cause and record what we changed.

9. Providers, your part, and reporting a vulnerability

Providers. Each provider that processes customer data is bound by a data-processing agreement. Each is listed, with what it receives and where, in our Subprocessor List.

Your part. Security is shared. Please:

• turn on two-factor sign-in, at least for owners and anyone handling payments or payroll;
• give each person the lowest role that lets them do their job, and remove people who leave;
• never share logins or API keys, and revoke keys you no longer use;
• keep your own exports of records you must retain.

Reporting a vulnerability. If you believe you have found a security issue, email support@yemoko.com with "Security" in the subject and enough detail to reproduce it. Please give us reasonable time to fix it before disclosing it. Do not access other people's data, and do not degrade the service. We will not take legal action against good-faith research that follows these rules.

Contact. Yemoko LLC, Texas, USA · support@yemoko.com