Question: Import ISO 27001 - which file format is needed?

[borishinzer]

Hi,
first of all, thanks for providing your software. I would like to evaluate it.
The Readme.md mentions I need to purchase on my own the ISO standard - but it doesn't say in which format. I assume it's PDF? Also, will the german version DIN EN ISO/IEC 27001:2024-01 (eg. mentioned here https://www.dinmedia.de/de/norm/din-en-iso-iec-27001/370680635) also work?

Best regards,

Boris

[jaserNo1]

I've been racking my brain over that, too. But above all, I'm wondering how the descriptions of the control requirements are stored and retrieved.

Anyway, thank you for the great tool!

[borishinzer]

At least I was able to convert the DIN ISO PDF which Claude Code to JSON, but after import the content doesn't show up in the SOA.

[AIMutant]

Mine neither..

I tried this style also but does not work:

[
  { "id": "ISO-5.1", "theme": "Organizational", "title": "Informationssicherheitspolitik und -richtlinien", "framework": "ISO 27001:2022" },
....
  { "id": "ISO-8.34", "theme": "Technological", "title": "Schutz der Informationssysteme während Tests im Rahmen von Audits", "framework": "ISO 27001:2022" }
]

In the Log it says:
admin | import | iso-controls | Imported 93 ISO controls

But no controls anywhere.. also tried it via the importer.. no controls.. even in docker compose I added the scripts folder and tried it there.. no SOA

[borishinzer]

I meanwhile think this is some kind of bug in the listing (as also the data didn't show up in our site). What helped my:

• Short term switch to json as storage engine - then the data (also sample data was there again)
• Migrated date with help of Claude Code to MySQL database as storage engine

[coolstartnow]

Hi Boris,

File format: Yes — you need a JSON file, not a PDF. ISO doesn't let us redistribute the standard's text, so the app never ships ISO 27001 control content; you provide it yourself. The expected format is documented in scripts/import-iso-controls.sh and used by the in-app importer (Admin → SoA → Import ISO Controls):

[
  { "id": "ISO-5.1", "theme": "Organizational", "title": "Policies for information security", "framework": "ISO27001" },
  { "id": "ISO-5.2", "theme": "Organizational", "title": "Information security roles and responsibilities", "framework": "ISO27001" }
]

Required fields per control: id, theme, title, framework. Important: framework must be the exact literal string ISO27001 (or ISO9000 / ISO9001) — not "ISO 27001:2022" or similar. @AIMutant's snippet above used "framework": "ISO 27001:2022", which doesn't match what the app looks for and is one reason those controls wouldn't be recognized correctly.

DIN EN ISO/IEC 27001:2024-01: That's fine to use — it's the German-language CEN adoption of ISO/IEC 27001:2022, same clause structure (4–10) and same Annex A control set (A.5–A.8), just localized wording/numbering. You'd transcribe the Annex A control titles from that edition into the JSON format above.

Re: "Imported X controls but nothing shows up in SoA" (also hit by @jaserNo1, @AIMutant) — I looked into this and found the actual bug: it's not about file format, it reproduces even with a correctly-formatted file. The in-app importer (POST /soa/import-controls) writes your JSON to data/iso-controls.json and then calls an internal "reload" — but the code that decides which ISO controls to merge into the live SoA data was cached once at server startup (server/db/soaStore.js, module-level USER_ISO_CONTROLS/ALL_SEED_CONTROLS). The reload after import doesn't recompute that cache, so newly imported controls are silently dropped from the merge even though the audit log correctly reports "Imported N ISO controls."

Workaround until this is patched: after importing via the Admin UI, fully restart the server process (not just reload the page) — npm start / bash start.sh / restart the container. That forces the cache to rebuild from the file you just wrote, and the controls will appear in SoA. This matches what @borishinzer found — the actual fix wasn't the storage-engine switch, it was the process restart that came with it.

We're tracking the underlying caching bug for a proper fix so a restart isn't required after import. Thanks all for the detailed reports — made this easy to pin down.