This page gives the plain-language version of the platform's security baseline. It states the five required controls as practices. It describes the audit trail that companies see. It states the incident-response commitment and the disclosure contact. Every control below is implemented and tested. Nothing here is aspirational.
//the five controls
User input never composes a filesystem path. Any path is derived from a server-side identifier, resolved, and checked for containment inside its allowed root before it is opened. Uploads go to object storage through validated, size-limited streams; downloads are served as signed, short-lived links, never rendered inline.
All database access uses parameterised queries. String-built SQL is prohibited without exception. Sorting and filtering use a fixed set of allowed keys. An unknown key is refused, and the platform does not build a query from it.
Free-text is stored as plain text and escaped on output; rich text renders through a single sanitising component with an explicit allow-list of tags and attributes; a strict Content Security Policy and strict headers apply to every first-party page.
One permissions matrix declares every capability and which roles hold it. Each route declares the capability it requires, and the server checks the capability on every request. The user interface is not a security control. The interface hides what a user cannot do, and the server checks the permission again.
Passwords are stored with PBKDF2-HMAC-SHA256 at 100,000 iterations, a per-user salt and constant-time comparison. API keys and refresh tokens are stored only as hashes, with an instantaneous revocation switch. No plaintext anywhere, ever.
The home page states the same five controls as commitments. This page is their full description, and the two pages must never disagree.
//the audit trail
Each company sees its own audit trail. The platform's governance process reviews cross-company access every month and records its findings. Access history is evidence, so the platform keeps it after a user leaves. The platform logs sensitive actions with the person who did them and the result. Sensitive actions include exports, booking acceptance and community registration.
//incident response
A documented incident runbook covers revoking sessions and keys, rotating affected secrets, assessing the exposure window through the audit log, and notifying the people and authorities that POPIA and GDPR require. The platform then records the event and the evidence of the fix. The legal deadlines are practised as runbook steps, and each step has a named owner.
Security disclosure: security@successledselling.co.za. The platform acknowledges a report within two business days. The address is published so that security researchers can report problems.
//where the privacy notice lives
Security and privacy are separate promises with separate notices. The controls above protect data. The privacy notice states what the platform collects, why it collects it, how long it keeps it, who sees it, and how to withdraw consent or delete data. The processing commitments that bind the platform as an operator are written in the data-processing agreement.
Success-Led Selling