Security
Records you can defend in front of an inspector
Security of a continuing airworthiness record system is not a padlock in the corner of the screen. It is that a record cannot be quietly changed, that a backup exists and is readable, that every action has an author, and that an outage has a written procedure. This page describes mechanisms, not declarations.
- Append-only records — deletion is blocked
- A SHA-256 hash chain across the event register
- A daily backup, separate from working data
- A paper procedure for outages, written down and rehearsed
Backups
Backups and the restore test
AMC1 ML.A.305 requires a backup updated within 24 hours of a new entry and kept separately from working data. Here is the schedule that delivers it.
| What | When | Where it lands |
|---|---|---|
| Full database dump | Every day, automatically | Media separate from the working database |
| Copy outside the production environment | Every week and before every system change | Operator-held storage, outside the application infrastructure |
| Hash chain verification | Daily after the backup and before every export for the authority | System log |
| Restore test from backup | Quarterly, on a test environment | A record in the operator’s documentation |
- A dump that cannot be read is deleted immediately and raised as an error — a make-believe backup must not pass for a backup.
- Restores always go into a new, empty database, never on top of the working one; hash chain verification afterwards is mandatory.
- Retention of the dumps themselves (30 days by default) is independent of record retention — the system does not delete data, so backups are not its long-term carrier.
Integrity
An audit chain that cannot be cut quietly
Every operation — creating an entry, signing, reversing, correcting a counter, recording compliance, assessing a bulletin, uploading a document, generating the authority pack — goes into the event register. Each row carries a digest that includes the digest of the previous row, so deleting, inserting or swapping any row breaks the chain.
Techlog signatures are verified separately: the digest is recomputed from the closed list of fields. A mismatch means a signed entry was changed after signing — and it is detectable even if the event register itself looks intact.
The check recomputes both: daily, and mandatorily before the authority pack is generated. The result is binary — consistent or not, with no shades in between.
-
Append-only records
Counter states are a stream of readings: every flight and every correction is a new row with an increment. The current value is derived from history rather than stored in a field that can be overwritten.
-
Locked in the database, not in the app
An attempt to change or delete a signed entry fails even for the operator database administrator. That is the difference between “the application will not let you” and “it cannot be done”.
-
Response to an inconsistency
We do not delete or “repair” data — the record is the evidence. An out-of-schedule dump is taken, the techlog moves to paper, and exports for the authority from that period are suspended until the matter is explained.
Access
Role separation and organisation isolation
An account belongs to exactly one organisation and holds exactly one role. Permissions are checked on the server and in the database, not by hiding buttons.
| Role | Can |
|---|---|
| Pilot | Create a techlog entry, sign their own entry, report a defect, view the aircraft, due lists and documents of their organisation. |
| Mechanic | Everything a pilot can, plus: recording task compliance, counter corrections, installing and removing components, the opening balance, uploading documents and bulletins, reversing an entry. |
| Administrator | Everything a mechanic can, plus: adding a new aircraft and configuring integrations. |
- A pilot cannot perform a mechanic action — the refusal sits on the server and in the database.
- The signatory is always the signed-in person; there is no way to indicate “on whose behalf” a signature is made.
- A user sees only their own organisation’s data — swapping an identifier in the URL does not reveal somebody else’s aircraft or entry.
All three rules have automated negative tests that run on every change to the system. The number of failed login and re-authentication attempts is limited by an exponentially growing lockout with an upper cap — so that a typo does not ground the crew for hours.
Infrastructure
Where the data lives
The application, the database and the scheduled jobs (backups, alerts, bulletin ingest) run at a single infrastructure provider, in an environment dedicated to production and separate from development and test. Demo data never reaches production.
The region of the production environment, the infrastructure provider and the list of sub-processors are agreed during the rollout and written into the data processing agreement. For operators who require data to stay inside the European Union, we confirm this in writing before we start — rather than with one sentence on a website.
Files (scanned aircraft documents, bulletins in PDF) are stored together with the data, so they are covered by the same backup. A backup that excludes attachments is a backup in name only.
-
Personal data of the crew
An import from an external system never creates accounts or people — linking requires manual confirmation. The login rate-limit register stores a digest of the e-mail address, not the address.
-
Separated environments
Production, test and development have separate databases. The script that purges demo data requires an explicit confirmation and never touches the event register.
-
Data processing agreement
Processing of operator data is governed by a separate agreement. The camobook.com information site is hosted separately and stores no cookies.
Retention
Records the system does not delete
Deleting an airworthiness record is technically blocked in the database. Withdrawing a document means marking it archived — it stays visible in history and in the authority pack. That is the simplest answer to the requirement to protect records against destruction: there is no button that could destroy them.
The retention interpretation we apply: detailed records (techlog entries, counter readings, task compliances, defects, the event register) — 36 months from the date of the record; summary and status records (aircraft documents, component installation history, the maintenance programme) — the whole operating life plus 12 months after the aircraft is permanently withdrawn. The interpretation is presented to the authority for acceptance, not announced as settled.
A retention report shows the factual position on any given day: what is held, since when, and what has passed the minimum period. The report deletes nothing — the fate of a record belongs to the operator, and when an aircraft changes hands its records go with it.
Outage
What happens when the system is down
The overriding rule: the absence of the system never stops flight operations and never excuses not keeping the logbook. The procedure is written down and binds crew, mechanics and the administrator.
- 01
Switch to paper
The logbook moves to the operator’s paper form with its own outage numbering. A paper entry must carry the same content as an electronic one, including both counter readings before and after the flight and the handwritten signature of the pilot in command.
- 02
Check the state once the system returns
Before anything is reconstructed, the integrity check is run. An inconsistency means no reconstruction — the matter is explained first.
- 03
Reconstruct in flight order
Entries are entered chronologically, transcribing fields one to one and quoting the paper form number in the remarks. The same person who signed the paper signs the entry.
- 04
Counter discrepancies
We never “stretch” a reading to make an entry pass. Either an earlier flight is missing, or a counter correction with a mandatory justification is required — later visible as a separate item, not as an ordinary flight.
- 05
Closing the procedure
Reconciling counters against the physical counter on the aircraft, reviewing due dates, re-running the integrity check, an out-of-schedule backup and a record signed by the CAMO manager. The paper forms stay in the records for good.
A failure of the PDF generator alone is not a system outage: the data stays available and the authority pack is produced with the CSV files and an explicit reason for the missing PDF in the manifest.
Plainly
What version 1.0 does not have
- Authentication is e-mail and password with attempt limiting. There is no second factor and no external identity provider yet.
- An account belongs to one organisation. The workshop and the authority receive the audit pack, not access to the system.
- The system does not assess the applicability of directives and bulletins — it supplies the documents and the trail of a human decision.
- The weekly off-site copy and the quarterly restore test need the operator administrator to take part. It is a procedure, not a button.
FAQ
Frequently asked questions
How do I show an inspector that nobody altered an entry?
With three independent things. First, the entry stores a SHA-256 digest of a closed list of its fields — recomputing it shows whether the content is the same. Second, the event register is bound by a hash chain, so deleting or swapping a row is detectable. Third, changing a signed entry is blocked in the database itself. The check recomputes both and its result can be shown during an audit.
What if you lose the data?
A restore runs from the daily dump, always into a new empty database, followed by a mandatory hash chain verification. The procedure is rehearsed quarterly on a test environment and the test record stays in the operator’s documentation — because a backup that has never been restored is just a file with a nice name. For the period between the last backup and the outage, the paper logbook from the outage procedure prevails.
Can a CamoBook employee see our fleet data?
Administrative access to the production database is held only by the person responsible for running the system, only for maintaining and repairing it, on the terms set out in the data processing agreement. Every action taken inside the application is recorded in the event register together with its author, and a signed entry cannot be changed regardless of access level.
Next
The nearest topics — on the site and in the knowledge base.
On the site
- Electronic techlog
One entry per flight, an electronic signature, immutability and work with no signal.
- Maintenance tracking
Hour, calendar and cycle limits, tolerances without drift, due-date forecasting.
- Pricing
Per aircraft, not per user: the pricing structure and how a rollout runs.
In the knowledge base
- The electronic techlog and Part-ML: what a record system must do
What ML.A.305 and AMC1 ML.A.305 expect from a computerised technical logbook, and what you actually have to show an inspector to leave paper behind.
- From paper to electronic records without losing history
The opening balance, the dual-run and the list of things to agree with your authority. What actually has to be transcribed, what must never be imported, and how long it takes.
See CamoBook on your own fleet
Thirty minutes, live: a signed techlog entry, the due list for your aircraft type and the audit pack. No sales deck — we talk about your maintenance programme.
or write to pawel@mamcarz.com