Obscura — standards & compliance position
Purpose. One honest source of truth for what Obscura can and cannot claim, so sales,
tenders and marketing copy stop guessing. Every claim below is written to survive a customer's
auditor asking "show me".
The rule this document exists to enforce: certification and conformance are different
words and mean different things.
- Certified — an accredited body audited it and issued a certificate. Only three parties
can hold one: the organisation, a specific deployment's operator, or nobody. - Conformant / built against — the product implements a standard's requirements. No
certificate exists, and for most product-level records standards none can exist.
Saying "certified" where only "conformant" is true is the kind of claim that loses a tender
and invites a complaint. Use the wording in the tables verbatim.
⚠️ Review before external publication. The standards interpretations here are
engineering's working understanding, not legal advice. An Indonesian records/compliance
advisor should confirm the ANRI and UU PDP positions before any of this reaches a customer.
1. What we may claim today
| Standard | Status | Approved wording |
|---|---|---|
| ISO/IEC 27001 (ISMS) | Certified — held by the company | "Developed and operated under our ISO/IEC 27001-certified information security management system." |
| ISO 16175 (records software requirements) | Product built against it; not certifiable by design | "Obscura is built to the ISO 16175 functional requirements for records management software." |
| ISO 15489 (records management principles) | Product aligns; guidance standard, no certification exists | "Aligned with the ISO 15489 records management principles." |
| ISO 30301 (management system for records) | Not held. See §3 | (no claim) |
Never write: "Obscura is ISO 16175 certified", "ISO 15489 certified", or "ISO 30301
certified". The first two cannot exist for any product; the third is not ours today, and when
it is, it certifies the organisation, not the software.
2. Evidence — what actually backs the ISO 16175 claim
These are implemented and verifiable in a live deployment. This table is the answer to a
tender's "describe how you meet this requirement".
| Requirement area | How Obscura meets it |
|---|---|
| Tamper-evident audit trail | Every audited event is HMAC-chained (AUDIT_CHAIN_KEY, held in config/KMS — never in the database, so a database compromise cannot forge entries undetectably). An hourly job re-derives the chain; UPDATE, DELETE and TRUNCATE are refused by database triggers set ENABLE ALWAYS, so they hold even under session_replication_role = replica. |
| Record history / extract | GET /documents/{id}/audit-extract returns one record's complete chained history, each event carrying seq, prev_hash, hash and key_epoch so a third party can re-verify it without us, plus our own verification verdict over exactly the ranges shown. |
| Retention & disposition | Schedules come from three sources — the document-type registry, the folder aggregation (inherited by nearest ancestor), and, with the klasifikasi module, the record's JRA row. Longest wins, so a narrow schedule can never silently shorten a broad one; ties break by specificity. GET /documents/{id}/retention/explain returns every candidate and the winner, because a rule this consequential has to be legible. Disposition actions: review / destroy / transfer. A daily sweep reports what is due. |
| Indonesian public-sector instruments | Optional klasifikasi module implements klasifikasi arsip + Jadwal Retensi Arsip (UU 43/2009 Pasal 40 and 48(1); approved per PP 28/2012 Pasal 53). Modelled 1:1 with the official table — two phases (retensi aktif at the unit pengolah, retensi inaktif at the unit kearsipan; the floor is their sum) and the three legal verdicts (musnah / permanen / dinilai kembali). Import-first, because a customer's schedule is approved by ANRI before it may be enacted: it arrives as a document, not as something authored in the app. Pemindahan arsip inaktif is implemented as the act it is: a batch, approved separately from the person who assembled it, that moves custody to the unit kearsipan and issues a signed berita acara serah terima with its daftar arsip. Completing one re-dates disposal from the ACTUAL handover — max(dispatch + aktif, transferred) + inaktif — so a late handover lengthens retention and an early one cannot cut short the aktif obligation. |
| Destruction with evidence | Destruction issues an append-only disposition certificate; blob deletion is reference-counted, so content shared between records is never destroyed with one of them. Automatic destruction is opt-in and ships dry-run-first. |
| Legal hold | A hold wins over every retention rule and is evaluated inside the deletion transaction, so a hold placed concurrently cannot be raced past. |
| Access control | Per-record and per-folder ACLs with deny-wins resolution across user, position, group and "everyone" subjects. Listings are filtered in SQL, never in the UI. |
| Record identity | Gapless, format-driven document IDs with provenance tracking; identifiers cannot be silently reassigned. |
| Integrity of the record | Frozen version snapshots; content-addressed storage (SHA-256); PAdES digital signatures with independent verification, including full /ByteRange coverage checking so content appended after signing is reported rather than trusted. |
| Security of the record | Encryption at rest for document blobs, signing keys, TOTP secrets and stored credentials (age/X25519). Optional forensic watermarking with a fail-closed egress policy. |
| Recoverability (tested) | A scheduled sidecar takes full disaster-recovery sets — pg_dump -Fc of the whole database plus a mirror of every document blob — with count-based retention. What makes this answerable rather than asserted: restore-drill.sh restores a set into throwaway containers and asserts the result, so recovery can be rehearsed on a live system at no risk and re-proven on a schedule. It checks that every content_hash the database references is present in the set, that the audit chain's sequences are continuous, and that the append-only triggers return as ENABLE ALWAYS — a restore that silently downgraded them would look compliant and not be. |
| Preservation format | Archival renders — a document's official copy, a finalized document, a numbered letter — are normalised to PDF/A-2b (ISO 19005-2, level B): every font embedded, external references forbidden, colour pinned by an output intent. The file declares its own conformance in XMP, so a recipient checks the claim against the artifact rather than trusting us. Configurable (ARCHIVAL_PDFA); previews and exports stay plain PDFs by design. |
| Search & retrieval | Full-text and semantic (vector) search, both ACL-filtered at the query. |
| Transfer to another custodian | GET /documents/{id}/transfer-package produces a self-describing ZIP: the record's content, its ISO 23081-shaped recordkeeping metadata, its full chained history, and a manifest with a SHA-256 per file. Plain ZIP and JSON — the recipient needs no Obscura to read or verify it. Anything the egress policy withholds is named with its reason and the package declares itself incomplete. |
Performing a transfer
The package obeys the same egress policy as an ordinary download. A deployment running
PROTECTION_NONPDF_EGRESS=block (the strict setting) therefore withholds any representation
that cannot carry the forensic watermark — typically the .docx/.xlsx source files, and
any PDF too short or too sparse to hide a mark in. The package still ships the record's
metadata and full history, names every withheld file with its reason, and reports
complete: false.
That is deliberate: a transfer must not become the quiet way around the watermark. To send a
complete package:
- Set
PROTECTION_NONPDF_EGRESS=auditand restart the backend. - Produce the package(s). Every export is written to the record's own audit history
regardless of the setting, so the transfer remains attributable. - Set it back to
block.
Check manifest.json → complete before handing a package over. An incomplete package is
usable — the metadata and history are whole — but it is not the record.
What is normalised to PDF/A — and what is not
Say this plainly rather than letting a customer assume more:
- Normalised: anything Obscura itself renders as the authoritative representation — a
document's official copy, a finalized document, a numbered letter. That covers records
authored in the system, which is most of them. - Not normalised: files an operator uploads. A scanned PDF is stored exactly as it
arrived, because re-encoding someone's received original would change the evidence rather
than preserve it. Their source.docxlikewise stays a.docx. - Not claimed PDF/A: a downloaded copy carrying a forensic watermark. Marking is
applied at egress to the copy being served; the stored record keeps its conformance, and
the download is a derived copy. - Best-effort: if the converter is unavailable the plain PDF is stored and the failure
logged. Because every file declares its own conformance, "did this one convert?" is
answerable from the artifact — do not assume uniformity across a corpus.
3. What we do NOT yet meet (state plainly if asked)
| Gap | Consequence | Planned |
|---|---|---|
| Key custody is the operator's, and it is absolute | Blobs are encrypted at rest and the keys are deliberately excluded from backups (ciphertext and its key in one directory would make the backup the softest target in the system). Lose the blob key and the backup is unreadable by anyone, including us — no vendor override exists. Sets record a key fingerprint so a mismatch is caught before recovery is relied on. | — |
| Folders double as the file plan | The aggregation carrying a schedule is the folder tree, which is also working structure — so moving a document can change which schedule reaches it. Longest-wins bounds the damage (a move cannot shorten an already-stamped floor), and the klasifikasi module offers a filing-independent scheme where that matters. | — |
No tata naskah dinas / SKKAA as formal instruments |
UU 43/2009 Pasal 40 names four instruments. Letterheads + numbering schemes cover the first in substance and ACLs + classification cover the fourth, but neither is presented as the named, auditable instrument an ANRI assessor looks for. | — |
| Uploaded originals are not normalised | Preservation covers what Obscura renders, not what an operator uploads: a received scan stays exactly as it arrived. Deliberate — re-encoding someone's original changes the evidence — but it means a corpus is not uniformly PDF/A. | — |
| No hybrid/physical records | Physical items and their locations are not tracked. Deliberately out of scope. | — |
4. Other standards
| Standard | Position |
|---|---|
| ISO 30301 | Certifiable, and the natural next certificate — see §5. Reuses ISO 27001's Annex SL clause structure, so the existing ISMS carries much of it. |
| ISO 23081 (recordkeeping metadata) | Companion to 15489. Met for transfer: the export package carries a declared metadata document per record (identity, agents, business context, governing rules). Not yet surfaced as a schema inside the app. |
| UU PDP (27/2022) | Indonesian personal-data law. A legal obligation, not a badge — requires a legal review of processing, not an engineering checklist. Not a marketing claim. |
| ANRI | Indonesian public-sector recordkeeping rules layer on top of the ISO family. Confirm applicability per customer. |
| SOC 2 / eIDAS | Not pursued. Only worth revisiting if a specific contract names them. |
5. ISO 30301 — what certification would actually take
It certifies the organisation, not Obscura. A certificate would say Virtue Digital
Indonesia operates a management system for records, and the marketing value is credibility as
a records-management vendor — "we run our own records the way we tell customers to". It would
not let us call the product certified.
It shares Annex SL clauses 4–10 with ISO 27001, which is the cheap part: context, leadership,
planning, support, operation, evaluation and improvement are structurally the same, and an
existing ISMS, internal-audit programme and management review can be integrated rather than
rebuilt.
What is genuinely new is records-specific content:
- Scope and context — which records, which business processes, which legal obligations.
- Records policy signed by leadership, with defined roles.
- Appraisal — decide what must be created and captured, and how long each class is kept.
This produces the retention schedule and file plan. - Controls in operation — Obscura is the instrument here, which is why the R1–R5 work
matters: it is where the evidence comes from. - Documented procedures — capture, classification, access, disposition, transfer.
- Competence and awareness — staff training records.
- Monitoring, internal audit, management review — evidence that it runs, not just exists.
Then the audit itself: Stage 1 (documentation review) → Stage 2 (implementation
evidence) → certificate, with annual surveillance and recertification at three years. Use a
KAN-accredited body, or an international one already auditing the 27001.
Effort is mostly not engineering. Expect the bulk in policy, appraisal and training, done
by whoever owns compliance — with engineering supplying evidence exports from Obscura. Aligning
the audit cycle with the existing 27001 surveillance visit is the main cost saver.
Timeline and fees vary by body and scope; get quotes rather than trusting an estimate here.
6. Recommended positioning
Lead with what is certified and true, support it with what is demonstrable:
"Obscura is built to the ISO 16175 functional requirements for records management software
and aligned with ISO 15489, and is developed and operated under our ISO/IEC 27001-certified
ISMS. Records carry a tamper-evident, independently verifiable audit trail, enforced
retention and disposition with destruction certificates, and legal hold."
Every clause there is backed by §2 and survives "show me".