Macct is not ISO 27001 certified. We still work systematically on technical and organisational measures to protect the accounting data our customers entrust to us. This page sets out which measures are actually in place, which are only partly in place, and what remains.
Last reviewed 19.10.2026. It is based on an internal review of source code, configuration and operational logs. It is not an external audit or security test.
Daily backups in a second data centre, with a restore tested every week. A controlled change process with a test environment and human approval. Per-company access control, a security log and HTTPS.
Encryption of stored data, vulnerability management for software libraries, supplier oversight, incident handling and privacy routines.
A formal information security management system, with a written policy, risk assessment and internal audit. There has been no external audit or security test either.
ISO/IEC 27001 is the international standard for information security management systems. The current edition is from 2022. The standard has two parts that are often confused.
Certification means that an accredited certification body has audited that the management system actually works over time. It does not say which technologies are used. HTTPS, encryption and backups are important measures, but they are not a management system.
For accounting software this matters a great deal. Your accounts contain vouchers, payroll, bank details and personal data about employees. The question is not only whether the system is secure today, but whether someone has an overview of the risks and follows them up systematically.
That is why we are not certified. Macct is developed and operated by Malloc AS, a small company. We have prioritised technical measures that protect the data directly. The formal management system the standard requires, with a written policy, documented risk assessment, Statement of Applicability, internal audit and management review, is not in place. We therefore do not claim that Macct meets the standard, and we have not set a date for certification.
We have only included measures for which we found concrete evidence in source code, configuration or operational logs. Under each measure we state what is not in place.
Macct runs at Hetzner in Helsinki (Finland). Backups are stored in a different data centre in Falkenstein (Germany). The accounting data is stored in the EU/EEA.
Only the services that must be reachable from the internet are open. The database and the secrets store cannot be reached from outside. Administrative access to the server requires a cryptographic key; password login and direct root login are disabled. Repeated suspicious attempts are blocked automatically.
Physical security of the data centres is handled by Hetzner. We have not assessed it ourselves.
Two-factor login is optional, also for administrators. That is a deliberate choice: you turn it on and off yourself under Security, and ten recovery codes cover a lost phone. We recommend that everyone with an administrator role turns it on.
All companies are in the same database. Every lookup is limited to the company the signed-in user has access to. In addition, the database has rules that prevent data in one company from being linked to another. Automated tests and code guards in the build check the separation, and it is checked again every week in a restored copy.
The separation is enforced by the application and by database rules, not by a separate database per customer. Our own reviews have previously uncovered weaknesses here, and they were fixed. No external party has tested the separation.
All traffic to macct.no uses HTTPS with automatically renewed certificates, and browsers are told never to use an unencrypted connection (HSTS). Email from Macct is sent encrypted to the mail server. Traffic between the application and the database does not cross the internet.
Database copies are encrypted before they leave the production data centre. The key needed to read them is not on the production server. Some particularly sensitive fields are encrypted in the application, including the secret behind two-factor login and credentials for connected point-of-sale systems.
The database and uploaded vouchers are not encrypted at disk level on the production server itself. There they are protected by access control and the provider's physical security. Copies of uploaded vouchers are not yet encrypted the same way as the database copies.
Passwords and keys for the database and for external services such as Altinn, banks and payments are kept in a dedicated secrets store, not in the source code. The test environment does not receive the production keys.
The database and uploaded vouchers are copied every day, and the copies are sent to a different data centre in a different country. The server provider also takes daily snapshots of the whole server.
A backup is only worth something if it can be restored, so this is tested automatically every week. A copy is fetched from the second data centre, decrypted and restored on a separate server. It is then checked that all tables and database rules are present, that the vouchers balance and that every company can be read back. In addition, a scrubbed copy is restored to the test server every night.
Our targets are to have the service running again within 8 hours, and to lose no more than 1 hour of data. They are targets, not guarantees. Restoring the database itself takes seconds, and a full restore on another server takes a few minutes.
The database and new or changed attachments are copied every hour, encrypted, to another data centre, and each copy is fetched back and checked. The data target is therefore met.
A full rebuild on a new server has not been rehearsed yet.
The security log records logins and failed attempts, denied access, keys being created and revoked, and when an accounting firm enters or leaves a company. The database rejects changes to and deletion of log entries, and the application itself cannot switch that protection off: it uses its own database user without ownership rights, while the tables are owned by a separate role nobody logs in as. A database administrator can still change the logging. The company administrator can read the company's own security log in Macct.
Posted vouchers are not changed silently. An error is corrected with a reversing entry, and changes to master data such as customers, suppliers, employees and settings are logged with the value before and after.
The operating system on the servers installs security updates automatically. The application and the libraries it depends on are updated through the same controlled change process as every other change.
We do not yet have automatic, systematic scanning of the software libraries for known vulnerabilities.
No change goes straight into production. Every change is built on a separate branch and tried on a separate test server against a fresh copy of the database. It runs through automated tests against a real database and is put forward as a pull request, which a human approves. Only then does an automated process deploy it, with a self-test afterwards; if that fails, the previous version keeps running. Database changes are dry-run against a copy before they are released. The details are in How Macct changes.
Much of the development and operations work is done by AI agents. They have technical restrictions: they cannot deploy anything themselves and cannot merge their own changes. The only exception is a narrow fast track for critical production errors. It requires a set of automated checks to pass, and it is closed to anything involving VAT, payroll, year-end, reports, rule sets and database structure.
The system is monitored around the clock. Availability is measured from outside several times an hour, production errors are picked up by automated guards, the accounting data is reconciled every night, and certificates and backups are checked daily.
Macct is a small company, and the human approval is done by one person. Separation of duties is therefore more limited than in a larger organisation.
Malloc AS is the controller for your account data and the processor for the accounting data you enter. The roles and the sub-processors are listed in the terms of use. You can export all the data your company has in Macct at any time. Vouchers you ask the AI features to read are sent to the language model provider for interpretation.
The test environment receives a scrubbed copy. Email addresses are replaced, phone numbers are removed, keys and bank connections are deleted, and the environment cannot send email.
The test copy still contains accounting and payroll data, so it is not anonymous. A data processing agreement is currently entered into on request, and we do not have a separate privacy notice beyond the terms of use. There is no finished routine for deleting a company's data once the retention period has expired.
Production errors are detected automatically, recorded in a log that cannot be changed, and fixed with a traceable change that can be linked to the original error report. Vulnerabilities can be reported to us as described below, and the address is in security.txt.
We have a written procedure for security breaches: who does what, how the damage is contained, and how the breach is assessed and notified. As the processor of your accounting data we notify you without undue delay, so you can decide whether the Norwegian Data Protection Authority must be notified within 72 hours. The procedure was rehearsed on the test server on 23.10.2026 with a leaked API token.
The rehearsal showed that we do not log which data an API token has read, only when it was last used. With a leaked token we must therefore assume that everything the token could access has been read.
The tables show how the measures in Macct relate to topics in ISO/IEC 27001:2022. The text in the column "What the standard covers" is our own summary, not the standard's wording. We did the mapping ourselves, and no certification body has reviewed it. A control being "in place" does not mean that Macct conforms to the standard.
In place = concrete evidence that the measure exists and works (not audited by others). Partial = some of it is in place, but significant parts are missing. Not in place = missing.
| Area | What the standard covers | What Macct actually does | Status |
|---|---|---|---|
| Context and scopeClause 4 | Understand requirements and interested parties, and define what the management system covers. | The legal requirements for accounting data are mapped point by point, but there is no written scope for an information security management system. | Not in place |
| Leadership and policyClause 5 | Management commits, sets a security policy and assigns responsibilities. | Responsibility lies with the management of Malloc AS, and the AI agents' permissions are defined and technically limited. There is no written security policy. | Partial |
| Risk assessmentClause 6 | A set method for assessing and treating risk, security objectives and a Statement of Applicability. | Risks are handled continuously as items in a prioritised work list. There is no documented risk assessment or Statement of Applicability. | Not in place |
| Support and documentationClause 7 | Resources, competence, awareness, communication and controlled documentation. | Operations, recovery and change procedures are written down and versioned. There is no training plan or formal document control. | Partial |
| OperationClause 8 | Carry out the planned measures and control changes and external deliveries. | Technical measures are in operation and tested regularly. They are not tied to a documented risk treatment plan. | Partial |
| EvaluationClause 9 | Monitoring and measurement, internal audit and management review. | Extensive technical monitoring and several internal security reviews. There is no set audit programme and no formal management review. | Partial |
| ImprovementClause 10 | Handle nonconformities, remove the cause and improve continually. | Every error is recorded and fixed with a test that proves the error, and recurring lessons are written down as permanent rules. Security nonconformities have no separate formal handling. | Partial |
| Area | What the standard covers | What Macct actually does | Status |
|---|---|---|---|
| Access controlA.5.15, A.5.18, A.8.3 | Access is granted on need, managed through its whole life cycle and limited to the right information. | Roles per company. Accounting firm access is checked on every request and can be revoked. Every lookup is limited to the user's own company. There are no regular, periodic reviews of access. | Partial |
| AuthenticationA.5.17, A.8.5 | Secure login and sound handling of passwords and keys. | Passwords are stored as bcrypt hashes. Account lockout and limits on attempts. Two-factor login is available but optional. Keys are stored only as hashes. | In place |
| Privileged accessA.8.2 | Administrative rights are limited and specially controlled. | Server access requires a key. Platform administration is restricted in the code. The AI agents' permissions are technically restricted. Two-factor login is optional, also for administrators, and recommended. | Partial |
| CryptographyA.8.24 | Rules for and use of encryption to protect information. | HTTPS and HSTS. Encrypted mail transport. Database copies are encrypted before they leave the data centre. Selected fields are encrypted in the application. There is no disk-level encryption and no written encryption rules. | Partial |
| BackupA.8.13 | Backups are taken and tested according to set rules. | Daily copies in a second data centre. Restore is tested automatically every week. | In place |
| ContinuityA.5.29, A.5.30, A.8.14 | ICT readiness and the ability to keep security and operations going during disruption. | Restore from a second data centre is tested weekly, and new versions are rolled out without downtime. Targets are set (running again within 8 hours, at most 1 hour of data lost) and a recovery plan is written, the database and new attachments are copied every hour, but there is no standby production server. | Partial |
| Logging and monitoringA.8.15, A.8.16 | Events are logged, logs are protected, and systems are monitored for anomalies. | A security log the database does not allow to be altered. The application itself cannot switch that protection off, because the tables are owned by a separate role. External uptime monitoring. Automated error guards and nightly checks. | In place |
| Protection of accounting recordsA.5.33 | Records are protected against loss, falsification and unauthorised change. | Posted vouchers are corrected only with reversing entries, master data changes are logged, and all data can be exported. | In place |
| Secure development and testingA.8.25, A.8.29 | Security is addressed throughout development, and changes are tested before use. | Automated tests against a real database and code guards for known error types. Every bug fix starts with a test that shows the bug. There has been no external security testing. | In place |
| Change managementA.8.32 | Changes to systems are controlled, approved and traceable. | Test server, a pull request approved by a human, and automated deployment with a self-test. There is a narrow, controlled fast track for critical errors. | In place |
| Separate environments and test dataA.8.31, A.8.33 | Development, test and production are kept apart, and test data is protected. | Test and production run on separate servers with their own keys. The test copy is pseudonymised: names, national identity numbers, addresses, account numbers and free text are replaced, and the attachments are swapped out. The AI agents cannot read the unscrubbed backups. Development work is not yet as strictly separated from operations. | Partial |
| VulnerabilitiesA.8.8 | Technical vulnerabilities are found, assessed and fixed in time. | The operating system installs security updates automatically. The software libraries are not scanned automatically for vulnerabilities. | Partial |
| NetworksA.8.20 | Networks are secured and managed to protect systems. | Only the necessary services are open to the internet. The database cannot be reached from outside, and repeated attack attempts are blocked automatically. | In place |
| Incident managementA.5.24–A.5.27 | Incidents are prepared for, assessed, handled and learned from. | Errors are detected automatically and fixed traceably. Written procedure for security breaches and notification, rehearsed 23.10.2026. Reads made with API tokens are not logged per call. | Partial |
| Suppliers and cloud servicesA.5.19–A.5.23 | Security is addressed in agreements with and follow-up of suppliers. | The sub-processors are listed on this page, with what they do and where. Servers and database are in the EU; the AI providers are in the USA. The agreements and the transfer basis have not been reviewed systematically. | Partial |
| PrivacyA.5.34 | Personal data is protected in line with the law. | The division of roles is described, and the data can be exported. There is no separate privacy notice, no standard data processing agreement and no deletion routine. | Partial |
| Physical securityA.7 | Premises and equipment are protected against unauthorised access and damage. | Macct has no server premises of its own. Physical security is handled by Hetzner, which we have not assessed ourselves. | Partial |
| Policy and independent reviewA.5.1, A.5.35 | Written security rules and regular review by an independent party. | There is no written information security policy, and no independent party has reviewed the security. | Not in place |
The control numbers refer to Annex A of ISO/IEC 27001:2022. The table is a selection. Controls we have not assessed are left out, and a control missing from the table is no claim that it is in place.
Technical measures are only part of information security. This is what actually exists on the organisational side, and what does not.
We have deliberately left out technical details that could help someone trying to attack the system.
These are the providers that process data on our behalf in running Macct, as of 23.10.2026. The list only shows integrations that are switched on in production. Bank connection (PSD2) through Neonomics or Finshark and the point-of-sale integrations with Zettle and Front Systems exist in the code, but are not in ordinary operation.
| Provider | What we use it for | What data | Where |
|---|---|---|---|
| Hetzner Online GmbH | Servers, database and backups | All data in Macct. Backups stored off the server are encrypted. | Finland and Germany (EU) |
| Domene.no | Email: sending invoices, payslips and notifications, and receiving vouchers by email | The emails and attachments | Norwegian provider |
| Anthropic | AI: posting suggestions, reading vouchers and bank PDFs, the assistant. Also our development tool, which works on a pseudonymised test copy | The content of the document or voucher being read, and what you write to the assistant | USA |
| Sign in with Google (if you choose it), page statistics without cookies, the map in travel expenses | Name and email for Google sign-in, page paths without ids, addresses you type in the map | USA | |
| Stripe Payments Europe | Card payment and automatic renewal of the subscription | Name, email and payment status. Card details are handled only by Stripe | Ireland (EU) |
| Klarna Bank AB | Payment with Klarna (via Stripe) | What Klarna needs for the payment | Sweden (EU) |
| Recommand | Peppol access point for electronic invoices (EHF) | The invoices you send and receive via Peppol | EU |
Altinn, Maskinporten, the Norwegian Tax Administration, the Brønnøysund Register Centre and Norges Bank receive information when you ask for a submission or a lookup. They process it under their own responsibility and are not sub-processors.
We have not yet systematically reviewed the data processing agreements and the basis for transfers to the USA (Anthropic and Google). The list in the terms of service is shorter than this one and will be updated in the next edition of the terms.
Every error and weakness we find, whether from automated checks, our own reviews or customer feedback, goes onto the same prioritised work list. It is fixed through the same controlled process as every other change, and the fix starts with a test that shows the error exists. Lessons that recur are written down as permanent rules.
The gaps described on this page are on that same list. When a measure changes status, we update this page. We do not promise a date for certification.
If you have found something you believe is a security weakness in Macct, write to firmapost@macct.no. Describe what you found, how it can be reproduced, and which page or feature it concerns. The address is also in security.txt (RFC 9116).
While investigating: use only your own account or a test account. Do not view, change or delete other people's data, do not put load on the service (denial of service or mass automated scanning), and do not try to trick customers or us into giving away information. Give us reasonable time to fix the issue before you publish it.
We confirm that we have received the report within five working days, assess how serious it is, and fix it according to severity through the same controlled process as every other change. We let you know when the issue is fixed. We do not run a bug bounty programme.
Good faith: If you investigate in good faith and within the limits above — without looking at other people's data beyond what is needed to demonstrate the issue, without denial of service, and telling us right away — we will not report you to the police or claim damages for the investigation.
Do you have questions about security, privacy or a data processing agreement, or have you found something you believe is a security weakness? Write to us at firmapost@macct.no.
Terms of use and privacy · How Macct changes · Does Macct meet the legal requirements?