One framework, and it is yours
We do not reason in European law. Our filing, notification and retention obligations are the ones set by Senegalese law.
Contents
1. Sovereignty is not a talking point, it is an address
It is our most concrete difference, so we put it first.
Futurize S.A.S is a Senegalese company. The processing of your data falls under the Senegalese Data Protection Act (Law No. 2008-12 of 25 January 2008), and the competent authority is the CDP — Senegal's Data Protection Commission, in Dakar.
What that changes on the day something goes wrong: the difference between filing with an authority in Dakar and starting proceedings on another continent is not a legal one, it is a practical one. Same time zone, same language of procedure, same body of law. A remedy you can actually use beats a right that is theoretically stronger but out of reach.
An authority you can reach
The CDP is your route of appeal if you believe we are handling your data badly. We do nothing to make that road longer.
SYSCOHADA from the ground up
Our accounting is natively SYSCOHADA — not a localisation module bolted onto a chart of accounts designed elsewhere. That is not security, it is accounting integrity.
2. Hosting and isolation
Your data is hosted in data centres located in Germany, operated by Hetzner Online GmbH, which holds ISO 27001 certification for its facilities. This transfer outside Senegal is declared, and we explain it in section 9.
The architecture rests on one simple principle: the databases cannot be reached from the internet by any path. They have no public address. Everything arriving from outside crosses a filtering edge first, then the application — never the data directly.
One company cannot see the others
Every record carries the company it belongs to, and the filter is applied in the application foundation rather than screen by screen — so one forgotten screen cannot open a breach between two customers.
No admin door left exposed
Our operations interfaces cannot be reached from the internet. They live on a private network entered with a named identity.
What is exposed is inventoried
The list of what answers from the internet is kept as a contract checked automatically. A service that showed up without being on that list fails the check.
3. Edge and segmentation
An attack that never reaches the application is an attack there is nothing to fix. Most of what aims at us is turned away before it gets to us.
Rules that block, not rules that log
Application rules turn away injection attempts and known attack patterns, on top of the managed rule set our edge provider runs. They block — they do not merely record.
Floods are absorbed at the edge
Application-layer denial-of-service protection sits in front of our servers. A flood does not have to cross our network to be shed, and our machines never see it.
A password already leaked is refused
Attempts using a credential known to appear in a public breach are blocked at the edge. That is the counter-measure to credential stuffing — the most ordinary and most effective attack against any online service.
Our servers only listen to our edge
The edge proves its identity to our servers with a client certificate. A request that went around the edge to hit the origin directly is not served: it cannot present that certificate.
Between our services: denied by default
Many intrusions succeed not because a door was open, but because once inside, everything was reachable. Here, every machine refuses inbound connections by default and opens only the paths that are declared, one at a time.
Our consoles are not on the internet
The interfaces used to operate the platform answer on no public address. They are reached from a private network, with a named identity — not a shared account, not a team password.
A list of addresses, not a password
Administrative access is restricted to a list of named addresses, held in the infrastructure code. Knowing a password is not enough: you also have to arrive from a declared place.
A single gate, and soon a second factor
Our operations consoles already sit behind a single access gate that admits company addresses only and lets no anonymous request through. What is still missing is the second factor: it requires connecting a full identity provider, planned for the end of September 2026.
4. Encryption
| Where | What is applied |
|---|---|
| Between you and us | HTTPS with systematic redirection. Nothing travels in the clear. |
| Between our components | Internal traffic runs over an encrypted private network, and the edge proves its identity to the origin. |
| Backups | AES-256. A backup that left our hands would be unreadable. |
| Passwords | Never stored — only a one-way fingerprint, computed with an algorithm designed to be slow. |
| Technical secrets | Centralised in a dedicated vault and injected at run time. No secret is written into our code, and an automated check blocks the release if it finds one. |
5. Authentication and access control
Two-factor authentication through a mobile app is available for all your users — including the highest administrative accounts. You decide who turns it on.
We would rather be accurate: this protection is available, not yet mandatory. So we cannot quote you an adoption rate. If your internal policy requires two-factor authentication for everyone, today it rests on your own discipline, not on a constraint we enforce — and we would rather tell you that than let you believe otherwise.
Fine-grained permissions
Rights are composed by role and by module. An accountant does not need to see payroll in order to keep the books.
Sensitive actions are logged
Who, what, when. Without that, an incident notification would be guesswork: we could say neither which data, nor which people, nor since when.
Named and restricted access
Our staff reach production through a named identity, on a private network. No shared access, no generic accounts.
6. Backups and recovery
The right question is not "do you take backups?" — everyone says yes. It is "how much can I lose, and when did you last verify it?"
| Property | Where we stand |
|---|---|
| Maximum data loss | 5 minutes — and that is not an estimate: a point-in-time restore was decrypted and replayed to verify it. |
| Immutability | A backup can be neither modified nor deleted during its protection window, including by us. That is the defence against ransomware that goes after the backups rather than the data. |
| Encryption | AES-256, before the backup even leaves the machine that produces it. |
| Time to restore service | ⚠️ The procedure has been validated in a test environment, but never timed on the real infrastructure. So we do not quote a figure. The exercise is scheduled. |
| Copy in a second region | ⚠️ Not in place. Our backups live in the same region as the platform. That is a cost trade-off we own, and would rather write down. |
7. Uptime — one figure, and how it is measured
We commit to 99.7% monthly uptime, effective 1 November 2026. That is 130 minutes a month — we write the minutes, because a percentage is easy to promise and hard to picture.
| Item | What we hold ourselves to |
|---|---|
| Scope | The application service. Adjacent services — documents, messaging, real time — are outside this commitment, and we say so. |
| "Available" | A valid response obtained by a probe outside our own network. |
| "Unavailable" | Two consecutive failed checks. The consequence we accept: an outage shorter than two minutes is not counted. |
| Maintenance | Announced 72 hours in advance and capped at 4 hours a month. Past the cap, the time counts as downtime. |
| Publication | The monthly figure appears on our public status page — including the months we miss the target. |
The four-hour cap is what makes the commitment real. Without it, "excluding announced maintenance" lets you hold any figure you like: you just have to announce. That is the clause we invite you to check elsewhere.
We do not grant service credits. Here is what we do instead.
Credits exist at most large providers. Three things are true of them: you have to claim them, they are capped, and they repair nothing. A 10% credit does not give back the day of invoicing your team lost.
Our four commitments
- Every outage appears on the status pageduring the incident, not afterwards.
- Every major outage gets a written report within 10 business daystimeline, cause, and what we changed.
- The monthly figure is publishedincluding — especially — the months we miss.
- An annual reporton uptime and incidents.
Why that is credible
- The practice already existsThe report on our incident of 28 August 2026 was written exactly that way: timestamped chronology, identified cause, five fixes with their status — including the ones that were not yet closed.
- A credit is claimed, negotiated, then forgottenA published report stays. We prefer the second, and we accept being held to it.
8. What a release has to go through
Every build is scanned
Known vulnerabilities in components are looked for at every build. A build that crosses the threshold does not ship.
The signature is not decorative
Every build is cryptographically signed, and the deployment refuses anything that is not. That is what stops a build swapped along the way from reaching production.
No secrets in the code
A blocking check looks for secrets on every proposed change. It does not warn: it stops.
Nothing ships unreviewed
Changes go through review and automated tests before they reach production.
We attack our own tokens
The tokens that grant access to a file go through a test that mutates them methodically and requires every alteration to be refused. The detail that matters is the witness: the test also fails when a mutation changed nothing — which is what stops a check from returning a reassuring result without having looked at anything.
9. Infrastructure described in code
Our servers are not administered by hand. They are described in a repository, reviewed like code, then applied by a machine. That is what makes a rebuild possible — and verifiable by someone other than whoever performed it.
The same fleet, on demand
A major incident is not repaired by guesswork. The description being complete, rebuilding is an execution, not an investigation.
Every change has an author and a date
An infrastructure change goes through review, like a code change. Nobody changes a firewall by logging into a machine.
What is not in the repository does not exist
A setting made by hand disappears at the next rebuild. That is deliberate: it stops the configuration from drifting away from its description without anyone noticing.
What this does not guarantee
Infrastructure described in code is the one we described — not necessarily a secure one. The review stays human, and the review is what does the work.
10. What we see
Three signals — logs, metrics, traces — arrive in the same place and cross-check each other. The rules that raise an alert are versioned like code, and a probe outside our network watches the platform the way you watch it.
Logs, metrics, traces
All three land in the same place and cross-check each other. A slowdown is traced back to the request causing it, instead of remaining an impression.
48 rules, versioned
An alerting rule is read, discussed and improved like code. It is not a setting clicked in an interface that nobody can find six months later.
A probe outside our network
Measuring your own availability from your own network is marking your own homework. The figure we publish is measured from outside.
What is watched is the age of the copy
Watching that a script ran does not say a backup exists. What raises an alert here is the age of the copy actually written.
11. Detection and response
Our monitoring runs without interruption: probes query the platform continuously, and any anomaly leaves immediately for our on-call channels. On top of that: a procedure written before the incident, committed deadlines, and the habit of publishing what happened.
Written before the incident
Who decides, who speaks, who pulls the plug. A procedure written during the outage is a procedure improvised.
To the CDP, not the CNIL
A personal-data breach is notified within 72 hours to the Commission de protection des données personnelles, in Dakar. The clock starts at knowledge of the incident, not at its full qualification.
A written report, and a public one
Timeline, cause, and what we changed. We also publish the outages nobody noticed: that is what makes the rest credible.
The watch does not stop at night
Uptime probes, alert rules on logs and metrics, and a watch on backup freshness: all of it runs continuously and notifies without human intervention. A Wazuh deployment is under way for detection on the machines themselves.
9. Independent audits
We hold no certification. We hold real audits, dated, whose findings are tracked — and whose results we publish, including when they are bad.
Application penetration test
Seventeen vulnerabilities — 4 critical, 6 high, 5 medium, 2 low. All closed by 26 April, twelve days. What matters is not how many were found, it is how long they took to close and the fact that seven automated tests now reproduce the scenarios: without them, a penetration test closes the same doors year after year.
External infrastructure audit
A remediation plan that is tracked, and whose findings feed our risk register and our security policy. It is what plays the counterweight today: our security lead is also our founder, and an outside pair of eyes is what keeps us from judging our own case.
Next cycle
A new penetration test and a new infrastructure audit are commissioned. We put a date on what is not done yet rather than leaving it out.
10. Your personal data
For the data you put into the ERP, you are the data controller and we are the processor. That distinction is not administrative: it settles who decides and who executes. We do not use your data for anything other than providing the service.
72 hours
If a data breach affects you, we tell you within 72 hours, alongside the notification to the CDP — even when it originates with one of our own subprocessors.
Hosting outside Senegal, declared
Your data is hosted in Germany. That transfer falls under articles 49 and 50 of Law 2008-12 and is part of our filings with the Commission.
A change is announced beforehand
Any change of subprocessor with access to your data is communicated to you before it happens, not in a later report.
Our weak spot, said plainly
We do not yet have a full export you could trigger yourself. Extracting your company alone is done manually today, with no turnaround time we can promise. The tooling is committed and dated; until then, we do not promise what we have not built.
For any question about your data or the exercise of your rights: [email protected] or [email protected].
11. Found a vulnerability?
Write to us at [email protected] or [email protected]. We would rather hear it from you.
What we owe you, and the limits of the game
What we owe you
- An acknowledgement within 3 business daysfrom a human, not from a robot.
- An assessment within 10 business dayswith our analysis, whether we accept the finding or not.
- Updates until the case is closedincluding when we conclude there is no vulnerability — and we tell you why.
- A place in the hall of fameunder the name of your choice, or none at all if you prefer.
- No legal actionfor good-faith research that stays within the scope opposite.
The scope
- In scopeOur public domains and the application reachable from the internet.
- Out of scopeDenial of service, social engineering of our teams or our customers, physical intrusion, and anything touching a real customer's data.
- On dataIf you reach real data, stop, do not copy it, and tell us. That is what separates research from intrusion.
- No bounty today — but a dated commitmentWe offer no financial reward at this time, and we would rather write that down than let you hope for one. This is not a matter of principle, it is a matter of cash. We will open a reward programme — material or financial — once we reach profitability or close a funding round, and researchers who report to us before that date will not be forgotten.
12. Hall of fame
The researchers who helped us fix a vulnerability, with their consent.
This table is empty, and we will not fill it with invented names.
Our disclosure programme opens with this page. The first line is still to be written — and if it is yours, it will carry the name you choose.
13. What we do not have
This section is unusual on a page like this. We keep it because a security expert knows that a page without one is hiding it — and because every line here would be found out anyway, by your auditor or by an incident.
What we are missing
- No ISO 27001 certification or SOC 2 report yet — but the framework is already appliedNo certificate does not mean no practice. We apply the framework ISO 27001 prescribes, and we document where we stand control by control across the 93 of Annex A — including where we fall short. What a certificate adds is not the practice: it is an accredited third party attesting to it. That programme is on our roadmap: starting in Q4 2026, targeted for Q2 2027. Until then we claim none, and if your procurement policy makes one a hard requirement, we are not eligible today — better to know now than three meetings from now.
- No hosting in SenegalTo our knowledge there is no local offering at this level. Our data sits in Germany, and that transfer is declared.
- No copy of the backups in a second regionA cost trade-off, and we own it.
- No round-the-clock human watchSignals are collected continuously and alerts fire at night; what does not exist is someone awake to receive them. A formal on-call rota is committed for 1 November 2026.
- No self-service full exportHanding your data back is a manual job today.
What we have that others do not
- Your own law, and an authority you can reachLaw 2008-12, recourse before the CDP in Dakar.
- A maximum loss that is quantified and verified5 minutes, decrypted and replayed — where the usual phrase "minimal to no data loss" cannot be checked.
- A control-by-control mappingWe document where we stand against each of the 93 controls of the international standard, marking what is in place, partial or absent. "Aligned with" is not "compliant with", and we will not write the second until an accredited body has established it.
- Evidence you can runOur claims rest on commands we can replay in front of you, not on a certification logo.
- Infrastructure described as codeServers, network, firewall, edge: all of it is declared in a versioned repository, and a drift check runs every night. A platform you rebuild identically from its code is not just faster to bring back — it is auditable: what runs is what is written, and any gap between the two shows.
- Native SYSCOHADANot a localisation bolted on afterwards.
17. The documents we keep
This page says what we do. It does not say what we can hand you. Here is the list, and on what terms.
We keep forty-five internal documents, built on the frameworks your auditor expects: the ANSSI guide crossed with ISO/IEC 27001:2022 for the security policy, ISO/IEC 25010 for quality requirements, ISO 22301:2019 for continuity, EBIOS Risk Manager for risk analysis, arc42 and C4 for architecture, and law 2008-12 for personal data.
These are not window dressing, and that is checkable rather than asserted. Each one carries a named owner, a review deadline, and the list of code files it depends on. A pipeline re-reads them every day and fails when a review is overdue, or when one of those files has moved since the last read-through. A document cannot declare itself current without being current.
Published, no conditions
| Document | What it covers |
|---|---|
| Terms of use | The contract governing use of the platform. |
| Privacy policy | Purposes, retention periods, your rights, and transfers outside Senegal. |
| Disclosure policy | How to report a flaw, how fast we acknowledge it, and our commitment not to pursue you. Also exposed as security.txt. |
Handed over on request, under a confidentiality agreement
| Document | What it covers |
|---|---|
| Information systems security policy | The root everything else derives from: 16 domains of the ANSSI guide crossed with the 93 controls of ISO/IEC 27001:2022. |
| ISO/IEC 27001:2022 statement of applicability | For each of the 93 controls: applicable or not, on the grounds of which risk or which law, and where the evidence is. It is the first piece a certification auditor asks for. |
| Technical architecture dossier | From context to deployment, in arc42 crossed with C4, with quality requirements mapped onto ISO/IEC 25010 and their target measures. |
| Functional architecture dossier | The map of the 26 modules of the platform, their dependencies and their scope. |
| Quality assurance plan | Branches, review, continuous integration, test matrices, versioning, and the chain that runs from source to production. |
| Awareness and training plan | What our people learn, and how we check that they have learnt it. |
| Acceptable use policy | The rules binding on our staff: workstations, accounts, support, use of generative artificial intelligence tools. |
| Architecture decisions | Eighteen decisions, one per file, each with its context, its trade-off and its negative consequences. |
| Documentary catalogue | The full list of the 45 documents, each with its scope and what you can obtain from it. It is the document you are reading in summary here. |
Also available on a reasoned request: our impact assessment on the human resources module, our procedure for responding to a formal demand from an authority, and the record of our access reviews.
Handed over by name, under a signed confidentiality agreement
| Document | What it covers |
|---|---|
| Security assurance plan | Fifteen chapters, from governance to service commitments, and the dated list of our gaps with their owner and their deadline. |
| Evidence dossier | The four pieces the plan above promises without negotiation: the two audit remediation summaries, the part of the processing register that concerns you, and the record of our recovery exercises. |
Those two are handed over together, to a named person, and every handover is entered in a register before it is sent: the version, the date, the recipient, and the agreement covering it. The day a version is superseded by a revision that changes a commitment, we know who holds which.
The rest does not leave, and we would rather write that than dodge it: several of these documents describe our access surfaces and our open weaknesses, and handing them over would amount to supplying the list of what to go looking at. What you get instead is not a watered-down version: it is a piece written to leave, carrying the same bad news. The security assurance plan declares seven named gaps; the evidence dossier writes that our own fix caused a global outage, and that two of our three real crises have no recorded time to recovery.
What the platform is built on
We name here what an observer already sees from the outside. The rest of our architecture is not secret on principle, but publishing it would amount to listing the components worth watching — and it would give you nothing.
Trademarks cited for information only, property of their respective owners.