Security

The page that answers the questionnaire

Every control below carries a status. Unfinished work is listed as unfinished, and nothing here is a certification we do not hold. The page says what is guaranteed, not how the machinery is laid out.

Updated October 2026

Short answers

What does an owner ask first?

Where the data lives, who can see it, what happens when someone leaves and how to get it out. Each answer is one line with its status, so you can copy it into a questionnaire. The detail for each sits in the sections below.

  1. Where is my data?In the European Union, and only there. Nothing is stored or replicated outside it.
    Implemented
  2. Can one shop see another shop's figures?A person assigned to a shop sees that shop. Seeing the whole company is a permission you grant, not a default.
    Implemented
  3. Someone leaves. What do I do?Remove them in Team and their sessions end on their next request. On Group, your directory does it for you.
    Implemented
  4. Who at BakeWise can see my data?Only to resolve a support request you raised or a security incident, and each access is recorded in the audit trail.
    In progress
  5. What if there is a breach?We notify you without undue delay after becoming aware of it, as the law requires of a processor.
    In progress
  6. Can I take my data out?Yes, at any time, in standard formats such as CSV and JSON.
    Implemented
  7. If I cancel, what happens to my data?It stays available for 30 days and is then erased. Billing records are the exception, as the next answer explains.
    Planned
  8. Can you erase my invoices on request?No. Invoices and tax-authority submissions are kept for the legal retention period and are never erased on request: the law requires it.
    Implemented
  9. Is my data used to train models for other customers?No. Forecasting models are per company and are never trained on another customer's data.
    Implemented
  10. What changes above 20 shops?Group: the same controls plus your directory for sign-in and joiners and leavers, and audit-log export.
    Implemented

Identity and access

Who gets in, with which permissions, and for how long?

People sign in with a password and a second factor, or through your company directory on Group. Permissions travel with the session and are checked on every request. Revoking a session or removing a person takes effect on the next request, and sessions can be listed and closed.

  1. SAML 2.0 single sign-onYour people sign in with company credentials against your identity provider. Responses are checked for signature, audience and time window, and a response that has been used is never accepted twice. Group only.
    Implemented
  2. Automatic joiners and leavers (SCIM 2.0)Your directory creates, updates and deactivates accounts, and deactivating someone removes their access to your company. Group only.
    Implemented
  3. Second factor, with lockoutA time-based code on top of the password, for accounts that do not sign in through your identity provider. Repeated wrong codes lock that person's verification.
    Implemented
  4. A declared access rule on every entry pointEvery entry point to the platform has a declared access rule, and a new one cannot ship without it.
    Implemented
  5. Joining a company takes an accepted invitationAn account that already exists joins a company only by accepting an invitation sent to its email address, and that address must have been verified by its owner. Inviting someone never adds them by itself, and internal services, API keys and demo sessions cannot accept in their place.
    Implemented
  6. Revocation on the next requestPermissions travel with the session, so every request is validated on its own: signature, revocation and permission freshness. A revoked session is refused even if it has not expired, and an invalid signature is a hard rejection with no alternative path.
    Implemented
  7. Sessions you can see and closeEvery active session is listed and can be closed one by one or all at once. Changing someone's role or department takes effect on their next request, not the next working day.
    Implemented
  8. Limits per company and per credentialEvery company and every credential has its own request ceiling, so an integration that runs away throttles itself without touching anyone else.
    Implemented
  9. Second factor required for the whole companyNot available today: each person turns it on for their own account.
    Planned
  10. Enforcing single sign-on onlyNot available today: password sign-in stays possible beside your identity provider.
    Planned
  11. Session lifetime set per companyNot available today: the lifetime is the same for every company.
    Planned

Isolation

Can another company ever see our data?

Each company's data is kept in rows labelled with that company, and the company is taken from the verified session, never from the request, so it cannot be faked. Every entry point has a declared access rule. Where a permission cannot be decided, access is denied.

  1. One company, its own rowsEvery row carries its company. The header that says which company a request is for does not come from the client: it is stripped from the incoming request and re-injected from the verified session, so it cannot be forged.
    Implemented
  2. Internal services are named before they can act for a companyWherever an internal service may act on behalf of a person, the access rule names it. A service that is not named is refused even with a valid credential, and that check is re-run on every change.
    Implemented
  3. Department-scoped permissionsProduction, procurement, quality, finance and people each see their own. Permissions resolve when the session starts, from the role and department pair, so there is no extra lookup per request. Available from Chain, and switched on person by person: assigning a department is what restricts.
    Implemented
  4. Parent and subsidiaries, failing closedA parent can read its subsidiaries' aggregated data when that network has it enabled; a subsidiary never reads its parent or its siblings. If the service that decides that permission does not answer, access is denied: when in doubt, we deny.
    Implemented
  5. One database per domainEach area owns its own isolated database rather than sharing one, so a failure or a heavy query in one cannot reach another's data.
    Implemented

Audit

How would you know a record had been edited?

Each write is chained to the one before it by a hash covering the whole record, so changing a single field breaks the chain. Updates and deletes are blocked in the database itself; a correction is appended, never overwritten. A scheduled process walks the chain every night, recomputes it and raises an alert.

  1. Hash chain over the whole recordEvery write is chained to the one before it by a hash that covers the entire record: who, what, from where, at what severity and with what detail. Change a single field and the chain breaks. A correction is appended, never overwritten.
    Implemented
  2. Verified every night, with alertingAn automated job walks the chain every night, recomputes each record and checks each link. If anything fails to add up, it raises an alert: this is a scheduled check whose outcome is recorded, not a button someone might press one day.
    Implemented
  3. Evidence an auditor can readEvery verification records which window was walked, how many records were checked and with what result. That history is what gets handed over in an audit, instead of a screenshot.
    Implemented
  4. Audit-log exportExport the audit trail for your own auditor. Group only.
    Implemented
  5. Gap-free fiscal numberingSequential invoice numbering with no gaps, guaranteed atomically per company and per year. Invoice and delivery note kept distinct, with taxable bases separated per VAT rate.
    Implemented

Data

Where does your data live, and how does it come back?

In the European Union, and only there: no replica and no storage outside the bloc. Traffic and the disks holding the databases are encrypted, and third-party credentials are kept encrypted by the application as well. Databases can be returned to a given moment, and one retained copy lives in a store where things can only be added.

  1. EU residency, and only the EUAll data at rest is stored in the European Union, with no replication to and no storage in any jurisdiction outside it. Access from outside the EU is governed by the data processing agreement. Residency is organisation-wide today, not a per-customer setting, and we say so plainly.
    ImplementedSubprocessor list in the privacy policy
  2. Encrypted in transit, and on encrypted disksAll traffic travels encrypted. The disks holding the databases are encrypted, and credentials for third-party systems, such as your ERP or your POS, are encrypted again by the application, so a database dump does not hand them over.
    Implemented
  3. Point-in-time recovery and an add-only copyThe databases can be returned to a specific moment, not just to last night's copy. On top of that, a retained copy lives in a store that can only be added to: nothing already there can be rewritten or deleted. That is the copy that survives ransomware.
    Implemented
  4. Recovery as measured, and drills in progressDatabases of record go back to a moment in time; other stores keep a daily copy. We state no recovery-time figure: it is set in the Group contract. Every store has a written restore procedure. Scheduled restore drills are in progress, and we will call them rehearsed the day the first one runs.
    In progress
  5. GDPR, with the rights actually workingNot a statement of intent: the rights are implemented as product features.
    ImplementedArticles 15 and 20: access and full data export in standard formats · Article 17: you confirm a deletion plan, it runs with retries and you can see its status; the records the law requires us to keep are named in the plan · Article 7: granular consent per processing purpose

Operations

How is the platform that holds your data run?

On several independent machines in the EU rather than one server, with the database layer replicated between them. Networks start by denying everything, and infrastructure is declared in code, reviewed before it is applied and auditable afterwards. What you will not find here is the provider, the city or a tool name.

  1. High availability and self-healingThe platform runs across several independent machines in the EU rather than one server, with the database layer replicated between them. When a machine is lost, the work it was carrying is rescheduled on its own.
    Implemented
  2. Segmented network, explicit permissionThe spaces where data lives start by denying everything: every connection that exists is declared, and what is not declared does not open. A compromised service does not find its neighbours by default.
    Implemented
  3. Every change versioned and reviewedInfrastructure and application are declared in code. Every change is versioned, reviewed before it applies and auditable afterwards; nothing is hand-edited on a running machine.
    Implemented
  4. Dependencies watched after release, not just beforeEvery build is blocked if it carries a known critical vulnerability, and we keep its component inventory, available on request. What is already deployed is re-scanned weekly: the code does not change, but what is known about it does. All the libraries each service depends on are also audited against published vulnerability advisories. When an advisory has no fix yet, it is recorded with its reason and a review date; we do not claim there are no known vulnerabilities.
    Implemented
  5. Forecasting models are signed and verified before useEach model is signed when it is trained and checked before a forecast uses it: signature, fingerprint and format. If anything does not match, the model is refused and nothing is loaded. Models are stored in formats that are read as data, never as code.
    Implemented
  6. Continuous monitoringTraces, metrics and aggregated logs across the platform, so an incident is investigated with evidence instead of reconstructed from memory.
    Implemented
  7. Internal reviews with simulated attackThe platform is reviewed against itself: security, infrastructure and code reviews that simulate an attacker, with every finding tracked to closure. As of October 2026, some medium-severity findings from the latest review are still queued for fixing.
    Implemented
For groups and procurement committees

Management system and assurance

Which certifications and tests do you hold?

None yet, and we say so. We are implementing an information security management system based on ISO/IEC 27001. We do not hold the certification, we have not engaged a certification body and no independent penetration test has been performed. Each item below has its status.

  1. ISO/IEC 27001:2022We are implementing an information security management system. Its scope, policy, risk assessment and a Statement of Applicability covering all 93 Annex A controls are drafted and await management approval. We do not hold the certification and have not engaged a certification body.
    In progress
  2. Independent penetration testNot yet performed. No date committed.
    Planned
  3. Continuous automated security testingPlanned. No date committed.
    Planned
  4. Platform hardeningIn phases. Admission rules refuse containers that do not meet the requirements (pinned image, read-only filesystem, declared resources) in the application and data spaces, and only watch in the rest. Outbound traffic on an allowlist advances step by step and today sits at the first step only: the next ones are not applied yet.
    In progress
  5. SOC 2Not started. No date committed.
    Planned
  6. Hosting providerThe data-centre operator holds its own ISO/IEC 27001 certificate for the data centre. That certificate is theirs, not ours.
    Implemented

Documentation

What do you hand over for a security review?

Six documents, each with its real status. Who processes data on our behalf and where; where every kind of data lives at rest; the article 28 processing agreement; the management system; the continuity plan; and the state of penetration testing. We would rather tell you what is missing than let you find it in due diligence.

DocumentStatusWhat it says
Subprocessor listImplementedThe subprocessor list: who processes data on our behalf, for what, with which categories of personal data and in which country. It is published in our privacy policy.
Residency statementImplementedThe residency statement: where each kind of data lives at rest and what transfers exist, if any do.
Processing agreement (art. 28)ImplementedThe Article 28 data processing agreement, with whichever standard contractual clauses apply.
Management system and Statement of ApplicabilityIn progressScope and Statement of Applicability. A summary under NDA once management has approved them.
Continuity planIn progressHow the platform is restored after a loss, store by store. Drafted, with restore drills in progress.
Penetration testingPlannedPenetration-test status: as of today no test by an independent third party has been performed. What does exist is documented internal reviews with simulated attack, and we will show you those.

Ask through the contact form and we send them. None of these documents sits behind a sales call.

Incidents and disclosure

What happens if something goes wrong, and how do I report a problem?

If personal data is breached we tell the customer without undue delay. If you find a weakness, tell us through the contact form with the topic security. We acknowledge within three working days, triage within ten and ask for a ninety-day window before anything is published.

  1. If we have a breachWe notify affected customers without undue delay after becoming aware of it, as the law requires of a processor, and tell them what we know and what we are doing about it.
    In progress
  2. Report a vulnerabilityUse the contact form with the topic security. Say what you found, where, and how to reproduce it. We do not offer an encrypted channel today, so keep the first message to what we need to find it and we will agree how to share the rest.
    Implemented
  3. What you can expectWe acknowledge within three working days and triage within ten. We ask for a ninety-day coordinated window before you publish, and we tell you when it is fixed.
    Implemented
  4. Good-faith researchIf you act in good faith and stay within scope, we will not take legal action against you. We do not run a bounty programme.
    Implemented
  5. ScopeThe public website and the application. Out of scope: denial of service, social engineering, and spam on the demo.
    Implemented
Report through the contact form

Food safety

What happens when a batch has to be pulled?

Every lot is traceable forward and backward, from supplier to customer, through production, inventory and sales. A recall quarantines synchronously and then notifies in the background, rate-limited and fully audited. Temperature is logged per zone and per equipment against configurable thresholds, and an out-of-range reading raises the alert by itself.

  1. HACCP temperature loggingContinuous temperature monitoring per zone and per equipment with configurable thresholds. Automatic alerts on out-of-range readings.
    Implemented
  2. Lot traceability, forward and backwardForward and backward traceability from supplier to customer. Every lot tracked through production, inventory and sales.
    Implemented
  3. Two-phase recall managementSynchronous quarantine followed by background notifications. Rate-limited to prevent abuse and fully audit-logged.
    Implemented
  4. Certificate of analysisGenerates compliance reports including HACCP audit, multi-standard summary, temperature logs and Certificate of Analysis in JSON or PDF.
    Implemented

Check it, do not take our word for it

The engine is open right now. Go in, look at the audit logs and ask whatever you like.

Open the live demo