Part-IS, demonstrated point by point.
Since 22 February 2026, Part-IS — Regulation (EU) 2023/203 — has required air operators, CAMOs, maintenance and training organisations, ATM/ANS providers and the other organisations listed in its Article 2(1) to run an information security management system for risks with a potential impact on aviation safety. AviIS is where that ISMS is run and kept as evidence, each record filed against the IS.I.OR point it answers.
With the optional AI assistant, threat scenarios, triage suggestions, report narratives, ISMM sections and compliance statements come as drafts — and a named person accepts or rejects every one. How the AI assistant works
Nothing to install. Hosted in the EU. It helps you demonstrate compliance; the ISMS stays yours.
Built on Part-IS, not around it.
Five texts decide what an organisation in scope has to set up and be able to show its competent authority. Each one has a home in AviIS, in the regulation's own vocabulary.
Reg. (EU) 2023/203, Annex II
Part-IS.I.OR — the organisation requirements
What it requires. An information security management system that covers the thirteen points of IS.I.OR.200(a) — policy, risk assessment and treatment, internal and external reporting, detection, response and recovery, measures notified by the authority, findings, contracted activities, personnel, records, compliance monitoring and the confidentiality of information received — plus continuous improvement, an ISMM and a change procedure, proportionate to the organisation (IS.I.OR.200(d)).
Where it lives in AviIS. A module for each point, and a compliance matrix with one row per requirement, so an inspector can walk the regulation and land on the evidence.
Reg. (EU) 2025/2293
Declared organisations
What it requires. A declared organisation needs no approval of its ISMM, of its amendments or of its change procedure, and may implement a change to its ISMS immediately. It still makes the ISMM available to the competent authority and sends it a copy of every amendment.
Where it lives in AviIS. Each approval or declaration is recorded with its competent authority. Where it is a declaration, ISMM revisions and changes skip the approval step and keep the record of what was sent to the authority.
ED Decisions 2023/009/R, 2025/014/R
AMC and GM to Part-IS.I.OR
What it requires. The acceptable means of compliance and guidance: the risk acceptance matrix of GM1 IS.I.OR.205(c), the reporting triggers of AMC1 IS.I.OR.230(a)&(b), the policy contents of AMC1 IS.I.OR.200(a)(1), the example threat scenarios and the ISO/IEC 27001:2022 mapping.
Where it lives in AviIS. The defaults are the AMC and GM: the matrix is Figure 1, the reportability question is the three AMC triggers, the policy checklist is points (a) to (j), and the controls register seeds from the 93 Annex A controls.
EASA Part-IS TF G-03, G-04
The oversight and proportionality guidelines
What it requires. G-03 sets how competent authorities assess implementation — Present, Suitable, Operating, Effective — and the four items to make available: the ISMM, the change procedure, an initial risk assessment and compliance monitoring evidence with a corrective action plan. G-04 shows proportional implementation for a simple organisation, including a three-factor likelihood score.
Where it lives in AviIS. The compliance matrix carries a PSOE level for every requirement, the dashboard tracks the four G-03 items, and the risk register scores likelihood the G-04 way when you choose to.
Reg. (EU) No 376/2014
Occurrence reporting, alongside
What it requires. Part-IS does not replace occurrence reporting. An occurrence that originated from an intentional unauthorised electronic interaction is reportable under both, and GM1 IS.I.OR.230(a)&(b) says the two should not become parallel reporting systems.
Where it lives in AviIS. The Reg. 376/2014 channel is one more recipient of the event, with its own clocks and the Article 13(4) analysis milestones beside the Part-IS follow-up, and the event exports as an E5X file for ECCAIRS 2.
One incident, three clocks, every recipient.
The steps below are the ones the application records for a reportable incident. The clocks run from the moment the condition became known to the organisation — IS.I.OR.230(c) counts from awareness, not from the event — and every step is written to the record's history by a server-side function.
Reported
Anyone can report it
Any member files an information security event from the browser — named, confidential or anonymous — with the affected elements, what was seen and what has already been done. It receives a reference such as ISE-2026-0014, and the time the organisation became aware of it is recorded as the start of every clock.
Triaged
Event, incident or vulnerability
The information security manager classifies it under IS.I.OR.215(b)(1) and answers the reportability question with the three triggers of AMC1 IS.I.OR.230(a)&(b): an occurrence under Reg. 376/2014 that originated from an intentional unauthorised electronic interaction, an incident with a potential significant risk to aviation safety, or a vulnerability not yet adequately mitigated. Significant risk means an unsafe condition.
Notification
As soon as the condition is known
A reportable event gets its recipients proposed: the competent authority of every affected approval, the design approval holder when an aircraft, system or component is affected, the organisation responsible for the design of an affected system or constituent, and the Reg. 376/2014 channel. Each has its own notification clock, against the organisation's target of 24 hours unless it sets another.
Report
72 hours, per recipient
The report to each recipient is due no later than 72 hours after awareness (IS.I.OR.230(c)(2)); filing later requires the exceptional circumstances to be written down. The overdue notice cannot be switched off. The report is generated as a PDF and an email draft, and as an E5X file with occurrence category ISEC for authorities that take reports through ECCAIRS 2.
Response
Contained, then back to a safe state
Containment and the measures taken (IS.I.OR.220(b)); recovery to a safe state of the affected elements within the recovery time the organisation defined for them (220(c)); emergency measures, with the residual risk accepted at the right level of accountability.
Follow-up
Recovery and prevention, reported
Once the actions are identified, the follow-up report goes to every recipient (IS.I.OR.230(c)(3)). The root cause, contributing factors and lessons learnt are recorded, and a lesson that changes a risk sends that risk back for review under IS.I.OR.205(d)(4).
Closed
Only through the gate
An event closes when it is classified, when every recipient has had its notification, report and follow-up, and — for an incident — when the root cause and the lessons learnt are written. It stays archived, never deleted, for at least the 5 years IS.I.OR.245(a)(4) requires.
| Recipient | Notification | Report (≤ 72 h) | Follow-up |
|---|---|---|---|
| Competent authority — AOC | Filed 09:40 | Due in 41 h 12 m | Not yet due |
| Competent authority — Part-145 | Filed 09:52 | Due in 41 h 12 m | Not yet due |
| Design approval holder | Filed 10:15 | Filed 16:05 | Not yet due |
| Reg. 376/2014 channel | Filed 09:40 | Due in 41 h 12 m | Not yet due |
Every IS.I.OR point has a place.
Each module is built on the point, the AMC and the guidance it answers, so the record it keeps is the evidence the point asks for. Every write is logged by a server-side function that no user can bypass.
IS.I.OR.215, 220
Events and incidents
The internal reporting scheme for every member — named, confidential or anonymous — with triage into event, incident or vulnerability, detection, response and recovery against each element's recovery time, analysis, internal distribution, and reassessment of the events kept on file.
IS.I.OR.230
External reporting
Three clocks per recipient from awareness — notification, the 72-hour report, follow-up — with recipients proposed from your approvals, a late-report justification, generated PDFs and email drafts, E5X export as occurrence category ISEC, and a log of every submission.
IS.I.OR.220, 230
Vulnerability alerts
The CISA Known Exploited Vulnerabilities catalogue matched every day to the vendor and product of your in-scope elements, conservatively and with a confidence level; the managers told of high-confidence matches on safety-relevant or critical elements; each alert dismissed with a reason on an append-only trail, or converted into a vulnerability event whose reportability is decided at triage.
IS.I.OR.205(a), (b)
Elements and interfaces
Registers of your activities, services, facilities, systems, equipment, data and networks, each with an in-scope decision, protection needs and recovery time — and of the interfaces with other organisations that could result in mutual exposure. The scope statement and the Appendix V proportionality self-assessment sit beside them.
IS.I.OR.205(c), (d)
Risk assessment
Threat scenarios associated with an element or an interface, rated on the GM1 IS.I.OR.205(c) acceptability matrix (3 to 5 levels per axis), likelihood optionally scored the G-04 way, conditional acceptance only by the accountable manager and only until a date, and reviews every 3, 6 or 12 months by acceptability and on the four review triggers.
IS.I.OR.210
Risk treatment and controls
A treatment plan for every unacceptable risk, its timeline accepted by the accountable manager, delays recorded and accepted, continued effectiveness checked, and the outcome communicated inside the organisation and to interfacing organisations. The statement of applicability seeds from the 93 controls of ISO/IEC 27001:2022 Annex A.
IS.I.OR.235, 215(c)
Suppliers and contracted activities
Parties and contracts, with contracted information security management activities kept apart from operational services; prior assessment, the clauses that matter — event reporting to you, a point of contact, access for the competent authority, audit rights — reviews and supplier audits.
IS.I.OR.200(a)(12), 225
Compliance monitoring
A requirements matrix with one row per Part-IS requirement and its G-03 PSOE level, ISMM cross-reference, evidence and corrective action plan; internal, supplier and authority audits; findings with Level 1, Level 2 and observation deadlines; authority findings and measures notified by the competent authority (200(a)(6)); feedback to the accountable manager.
IS.I.OR.200(e)
Derogation
The application to be exempted from points (a) to (d), built with the content the EASA guidelines list and prefilled from your registers, signed by the accountable manager — with the decision, the periodic validity review, and the reminder of what still applies afterwards.
IS.I.OR.240, 245(b)
People and acknowledgements
The accountable manager, the person or group of IS.I.OR.240(b) and their deputies, compliance monitoring and the common responsible person, on an organisation chart; roles each person acknowledges in the application; competence, identity and trustworthiness records; training, awareness notices and staffing.
IS.I.OR.250, 200(a)(1)
ISMM and policy
The ISMM built section by section against IS.I.OR.250(a)(1) to (10), with the accountable manager's statement signed in the application and countersigned by the CEO where they differ, revisions, and a cross-reference to Annex II. A declared-organisation mode drops the approval step. The information security policy is checked against AMC1 IS.I.OR.200(a)(1) and published for acknowledgement.
IS.I.OR.255, 210
Changes and actions
Each change to the ISMS routed as covered by your approved procedure, needing prior approval, or without ISMS impact; the AMC1 IS.I.OR.255 content; approval before implementation, except for declared organisations. Every treatment, corrective and improvement action in one tracker with an owner, a due date and verification of effectiveness.
IS.I.OR.260
Continuous improvement
Performance indicators covering the areas GM1 IS.I.OR.260(a) names, with targets and monthly measurements; maturity assessments on a five-level model or the PSOE scale; management reviews chaired by the accountable manager, with the improvement actions they raise.
IS.I.OR.245
Records and reports
Retention the way IS.I.OR.245 sets it, archive instead of delete, a history of every change, and the exports the authority asks for: the audit pack, the compliance matrix, the risk register and treatment plan, the statement of applicability and a workbook of every register.
An assistant that drafts, and a person who decides.
The AI assistant is an optional add-on. It drafts the Part-IS work that takes hours — threat scenarios, a triage suggestion, the narrative of a report to the authority, an ISMM section, a compliance statement — and finds the section and page of your own manuals that apply. Each draft waits for a person.
- Drafts where the work is done
- Threat scenarios for an element or interface, rated on your matrix (IS.I.OR.205(c)); a triage suggestion with the AMC1 IS.I.OR.230(a)&(b) trigger (215(b)(1), 230(b)); the narrative of a notification, report or follow-up (230(c)); an ISMM section from your registers (250(a)); how a requirement is met, with the evidence and the gaps (200(a)(12)).
- References, with the page
- Your manuals are indexed once per revision. Ask a finding or a change for references and it returns up to three — the document, the section, the page, and why — and opens the page before you accept anything.
- Labelled until accepted
- Every draft carries “Suggested by AI, not verified” and is written nowhere until a named person keeps, applies or uses it and saves. It decides nothing and sends nothing to an authority.
- De-identified, and never TLP:RED
- Names, email addresses, phone numbers and aircraft registration marks are replaced before anything leaves the server. Records marked TLP:AMBER+STRICT or TLP:RED are never sent.
For the organisations Part-IS names.
Article 2(1) of Regulation (EU) 2023/203 lists who must comply. AviIS is built for the organisations on that list that answer to a competent authority under Part-IS.I.OR, from a two-person training organisation to an airline.
Air operators and CAMOs
Operators under Part-ORO and continuing airworthiness management organisations under Part-CAMO, unless their activity falls within the exclusions of Article 2(1) — ELA2 aircraft, small single-engine day-VFR operations, Part-ML only.
Maintenance, training and medicine
Part-145 maintenance organisations, approved training organisations, aero-medical centres and FSTD operators: the same ISMS, proportionate to the nature and complexity of the activity (IS.I.OR.200(d)).
Air traffic and U-space
ATM/ANS providers under Part-ATM/ANS.OR, ATCO training organisations and ATCO aero-medical centres, U-space service providers and single common information service providers.
Several approvals, one ISMS
An organisation holding several approvals records each one with its competent authority. Reports go to the authority of every affected approval, as GM1 IS.I.OR.230 describes, and one ISMM may cover them all (GM1 IS.I.OR.250(a)).
Five roles, and the post beside them
A user belongs to exactly one organisation. The role is a claim on the user's sign-in token, set only by a server-side function, and the security rules enforce it on every read and write. Beside it sits the person's post — Accountable Manager, Information Security Manager, Compliance Monitoring Manager, common responsible person, IT manager — which decides routing rather than access: who is told about a new event, who owns an action, who may accept a risk or approve a change.
- Administrator
- Everything, including users, invitations and settings.
- Information security manager
- Runs the ISMS: events and incidents, external reporting, risks, scope, suppliers, compliance, people, documents, improvement and reports; settings, users and the audit log read-only.
- Auditor
- Compliance monitoring in full — audits and findings; creates and updates actions but does not verify them; reads everything else, including settings and the audit log.
- Reporter
- Every member of staff: reports events and follows their own, reads documents and notices, acknowledges the policy and their roles, and progresses the actions assigned to them.
- Viewer
- Read-only across the organisation — for an accountable manager who does not operate the tool, or an inspector's account.
Where your data lives, and who can touch it.
IS.I.OR.245(d) asks for records protected from damage, alteration and theft. Every decision below exists so that an inspector's question about your records has a short answer.
Google Cloud, europe-west1 (Belgium)
The database, file storage and server-side functions are all pinned to one EU region.
One organisation, one boundary
Every record lives under your organisation. The security rules compare the organisation on the user's sign-in token with the path of the record on every read and write, so a query cannot reach another tenant's data.
Information from others, protected by level
Events, risks, interfaces and authority directives carry a Traffic Light Protocol marking. TLP:AMBER+STRICT and TLP:RED records are readable only by the information security manager, administrators and the people named on the need-to-know list — enforced by the security rules, as IS.I.OR.200(a)(13) asks.
Confidential and anonymous reports
A confidential report shows no name on the record; the identity is stored in a restricted sub-record only the information security manager and administrators can read. An anonymous report carries no identity at all.
A history nobody can edit
Every change to a record is written to its history, and every write to the organisation's audit log, by server-side functions. Administrators, the information security manager and compliance monitoring can read the log; nobody can change it.
Archive, never delete
Records are archived, not removed, and kept as IS.I.OR.245 sets: risks, incidents and key processes for 5 years, contracts for 5 years after they end, personnel records for 3 years after the person leaves, and retained events until they are reassessed.
Deadlines that chase themselves
Scheduled functions look for what is falling due — triage, notifications, 72-hour reports, follow-ups, risk reviews, conditional acceptances about to expire, findings, directives, contract reviews, trustworthiness rechecks — and tell the people responsible. Another checks the CISA catalogue of exploited vulnerabilities against your elements every morning.
The AI assistant sees no reporter
Where the optional assistant is switched on, it never receives a reporter's identity or the witnesses; the names AviIS holds, email addresses, phone numbers and aircraft registration marks are replaced before anything leaves the server, and TLP:AMBER+STRICT and TLP:RED records are never sent. It suggests; it never writes a record on its own.
Questions information security managers ask first.
- Is AviIS approved by EASA or a competent authority?
- No — and no software is. Under Part-IS the competent authority approves the ISMM (unless the organisation is declared) and assesses the ISMS through its oversight; it does not approve tools. AviIS is built to the structure of Part-IS.I.OR and its AMC and GM so that an organisation can demonstrate compliance point by point. Agree your arrangements with your competent authority.
- Does AviIS send reports to the authority?
- No. IS.I.OR.230(c) leaves the form of the report to each competent authority. AviIS generates the notification, the report and the follow-up as PDFs and email drafts, and as an E5X file with occurrence category ISEC (ECCAIRS taxonomy 7.1.0.0 by default) for authorities that take reports through ECCAIRS 2. You send them, and record each submission against its recipient, which stops that clock. The information security attributes of the ECCAIRS taxonomy are new: check them against your authority's taxonomy version before the first use.
- How does the 72-hour clock work?
- It starts when the condition became known to the organisation — the awareness time recorded on the event — not when the event happened. Each recipient has its own notification, report and follow-up clock. The report is due within 72 hours (IS.I.OR.230(c)(2)); a later filing needs a written account of the exceptional circumstances. The overdue notice goes to the posts the organisation names — by default the information security manager, the compliance monitoring manager and the accountable manager — and cannot be switched off.
- We already run an SMS. Do we need a second system?
- Part-IS allows integration: IS.I.OR.200(d) lets the ISMS be integrated with existing management systems, IS.I.OR.215(e) lets the internal reporting scheme be integrated with other reporting schemes, and IS.I.OR.250(d) lets the ISMM be part of another manual with a clear cross-reference. What an SMS does not usually model is the Part-IS record itself — elements, interfaces, threat scenarios, recipients per approval, the ISMM contents. AviIS keeps that record and produces the cross-reference for an integrated manual. AviSMS, from the same company, covers the safety management side.
- We are a declared organisation. What changes?
- Since Regulation (EU) 2025/2293, a declared organisation does not need its ISMM, its amendments or its change procedure approved, and may implement a change to its ISMS immediately. It still makes the ISMM available to the competent authority and sends a copy of every amendment. Mark the declaration as such in AviIS and the approval steps disappear, while the record of what was sent remains.
- Can a small organisation run it on its own?
- That is what it is designed for. IS.I.OR.200(d) asks for processes that correspond to the nature and complexity of the activity, and the EASA G-04 guidelines show what that means for a simple organisation. The default matrix is the three-by-three of GM1 IS.I.OR.205(c), the Appendix V self-assessment records why your implementation is proportionate, and the ISMM builder fills the sections it can from the registers you already keep.
- Is there AI in it, and what does it do?
- There is, as an optional add-on. It drafts threat scenarios for an element or interface, a triage suggestion for a reported event, the narrative of a notification, report or follow-up, a section of the ISMM and the statement of how a requirement is met, and it suggests the section and page of your own manuals that apply to a finding or a change. Every draft is labelled as unverified until a named person accepts it; it decides nothing and sends nothing to an authority. Inputs are de-identified, and records marked TLP:AMBER+STRICT or TLP:RED are never sent. How the AI assistant works
- Does AviIS find vulnerabilities in our systems?
- It does not scan anything. Every morning it matches the CISA Known Exploited Vulnerabilities catalogue — vulnerabilities known to be exploited in the wild — to the vendor and product recorded for each in-scope element, conservatively, with a confidence level. High-confidence matches on safety-relevant or critical elements are notified to the posts you name and the administrators; entries added to the catalogue more than 24 months earlier are listed apart. Each alert is dismissed with a reason or converted into a vulnerability event, where reportability under AMC1 IS.I.OR.230(a)&(b) is decided. CISA KEV is the only feed.
- Where is the data stored?
- On Google Cloud in europe-west1 (Belgium). Each organisation's data lives under its own path and is isolated by security rules; history and the audit log are written only by server-side functions.
- How do we start?
- Create your organisation at app.aviis.aero, which makes you its first administrator. Record your approvals and their competent authorities, invite colleagues — each invitation is a link valid for 7 days — and adjust the reporting targets and the risk matrix if your ISMM says otherwise. There is nothing to install.
- What does it cost?
- €1,800 a year for an air operator with one or two aircraft, €1,188 for a training organisation with one or two, €3,000 for any other Part-IS organisation up to 25 staff. It is a flat annual fee for the organisation: every module and unlimited users in every role, with no per-seat charge. 60 days to try it first, and an invoice rather than a card. The full price list
Start with your organisation.
Create it in a minute, record your approvals and competent authorities, and invite your information security manager. The defaults — the acceptability matrix, the 72-hour clock, the review periods — are the regulation's; change them in Settings when your ISMM says otherwise.