Security and Data Protection

This page describes the security controls Lenucs actually uses today. We don’t hold security certifications such as ISO 27001, SOC 2 or PCI DSS, and no online service can be completely secure. We use reasonable measures for the kind of information we handle, and we keep improving them.

Access and isolation

• Each workspace’s data is separated by row-level security in the database. Every query is checked against the signed-in person’s membership and role, so one workspace can’t read another’s data.
• Roles inside a workspace control who can view, edit, delete and manage records.
• Public visitors can only use specific, limited functions (view a published form, submit it, place an order, report a link). They have no direct access to tables.
• Lenucs staff use a separate admin site that requires a password and an authenticator-app code on every sign-in. Access is limited by role and page, and admin actions are recorded in an audit log that staff can’t edit or delete. Entries are kept for 2 years.

Accounts and sessions

• Passwords are stored by our authentication provider as one-way hashes.
• Sessions are kept in first-party cookies and refreshed regularly. Signing out ends the session in your browser.
• New accounts confirm their email address with a link.

Data in transit and at rest

• The website, Console and public pages are served only over HTTPS.
• Data is stored with Supabase, which encrypts its databases and storage at rest.
• Secret keys (for example for AI and admin integrations) are kept on the server and never sent to browsers.

Files

• Form uploads and verification documents are kept in private storage and opened only with short-lived signed links.
• Upload size and file types are limited.
• Verification documents are deleted automatically 30 days after a decision.
• Workspace logos, profile photos and product images are public by design so they can be shown on pages.

Abuse prevention

• Rate limits on form submissions, orders, enquiries, reports and privacy requests, and hidden spam traps on public forms.
• IP addresses are never stored in our database. Where we need to recognise repeat visitors for rate limits, we store a one-way hash whose secret key changes daily.
• Console pages can’t be embedded in other sites (clickjacking protection), and browsers are told not to guess content types.
• The installable app does not store signed-in pages on your device.

Operations

• Database backups are managed by Supabase according to our project plan.
• Scheduled jobs clean up data when its retention period ends.
• Changes to the database are made through versioned migration scripts kept in our code repository.

• Use a strong, unique password and keep your email account secure.
• Give team members the lowest role they need, and remove people who leave.
• Don’t collect information you don’t need (see the Acceptable Use Policy). Keep exported files safe.

If we suspect a security incident, we will:

• investigate it;
• contain it and limit the damage;
• work out what information and which customers are affected;
• fix the cause.

Where there are reasonable grounds to believe personal information was accessed or acquired by an unauthorised person, we notify the Information Regulator and affected people as soon as reasonably possible, as section 22 of POPIA requires. Where we hold the information for a Customer, we notify that Customer so it can meet its own obligations. Every incident is recorded in our internal incident register and reviewed afterwards.

If you find a security issue, please report it through our contact form (choose “Legal”) with “Security” in the subject, and give us reasonable time to fix it before sharing it. Don’t access other people’s data, disrupt the service or run automated scans. We don’t run a paid bug bounty.