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.
An identity provider, and it is not here yet
Our operations consoles will move behind a single identity provider with mandatory two-factor authentication. Planned for the end of September 2026 — so it is not in place today, and we would rather date it than let it be assumed.
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. 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].
11. Found a vulnerability?
Write to us at [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 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.
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.