What it does, point by point.

AviIS is a web application organised the way Annex II to Regulation (EU) 2023/203 is: a module for each IS.I.OR point, each keeping the record that point asks the organisation to be able to show. It runs in the browser, stores everything under one organisation in the EU, and uses the AMC and GM as its defaults — the acceptability matrix, the reporting triggers, the review periods, the ISMM contents — which you can change where your ISMM says otherwise.

IS.I.OR.215, 220, 245(a)(1)(v)–(vi)

Events and incidents

The internal reporting scheme, and the detection, response and recovery that follow it.

A report form for every member of staff: when it happened, when it was detected and when the organisation became aware; the category; the affected elements from the register; what was seen and what was already done; the impact on confidentiality, integrity, availability, authenticity and safety.
Three ways to report: named, confidential (the identity is stored in a restricted sub-record) or anonymous. The form carries the just culture wording, and named and confidential reporters follow their own reports and the feedback on them.
Triage by the information security manager: not relevant, event, incident or vulnerability (IS.I.OR.215(b)(1)); safety impact; the reportability question with the three triggers of AMC1 IS.I.OR.230(a)&(b); the Reg. (EU) No 376/2014 obligation; an immediate-hazard flag that asks for the authority to be advised by the fastest possible means (AMC1 IS.I.OR.230(c)).
Vulnerabilities carry their CVE identifiers, exploitability, the remediation due date and mitigation status, because an unmitigated significant vulnerability is itself reportable.
Response and recovery (IS.I.OR.220(b), (c)): containment and its criteria, the measures taken, the recovery time proposed from the affected elements, when a safe state was reached, and emergency measures with the residual risk accepted by the right person.
Analysis: root cause, contributing factors and lessons learnt, linked to the risks they change (IS.I.OR.215(b)(2)); internal distribution recorded (215(b)(4)); cooperation with other organisations recorded (215(d)).
Events that are not incidents get a reassessment date — every 90 days by default — so records kept to reveal undetected incidents are reassessed as IS.I.OR.245(a)(5) requires.
Status new → triage → response → recovery → review → closed, with a closing gate; TLP marking and a need-to-know list on each record; sequential references (ISE-2026-0001) and a full history.

An information security incident record: a ransomware event marked incident, critical, significant (unsafe condition), reportable under IS.I.OR.230 and TLP:AMBER, with the 72-hour report deadline, the report as submitted, the affected element and the timeline. — A reportable ransomware incident in the demonstration organisation: classification, TLP marking and the 72-hour deadline at the top, the report as submitted below.

IS.I.OR.230

External reporting

Notification, report and follow-up to every recipient, each against its own clock.

Clocks from awareness, per IS.I.OR.230(c): notification as soon as the condition is known (the organisation's target, default 24 hours), the report within 72 hours, the follow-up once the recovery and prevention actions are identified (target 30 days).
Recipients proposed from the organisation's approvals and the event: the competent authority of every affected approval (GM1 IS.I.OR.230 — two AOCs, several approvals, organisations outside the EU reporting to EASA), the design approval holder (230(b)(1)), the organisation responsible for the design of a system or constituent (230(b)(2)), and the Reg. 376/2014 channel. Editable.
A recipient × stage grid showing what is not yet due, due, overdue or filed, and when.
A report filed after 72 hours cannot be recorded without the exceptional circumstances that prevented it.
Where Reg. 376/2014 applies, the Article 13(4) analysis milestones — preliminary within 30 days, final within three months — sit beside the Part-IS follow-up.
For each stage, a PDF on the organisation's letterhead with the approvals, the competent authority, the TLP marking and the information security manager as point of contact, and an email draft to the recipient.
E5X export for ECCAIRS 2 with occurrence category ISEC and the taxonomy version recorded (default 7.1.0.0). The information security attributes of the taxonomy are new; check them against your authority's taxonomy version before the first use.
Every submission logged with its stage, recipient, channel, time, external reference and the file sent — never deleted. Recording the first submission of a stage stops that recipient's clock.
Notifications when a notification or report falls due and when it is overdue. The overdue ones cannot be switched off by any member: the evidence that the accountable people were told must not depend on a personal preference.

The external reporting tab of an incident: the notification, 72-hour report and follow-up clocks of IS.I.OR.230(c) side by side, and the recipient list with the competent authority and the approvals it covers. — The three IS.I.OR.230(c) clocks of the same incident, and the competent authority proposed from the approvals it affects.

IS.I.OR.220, 230(b); GM1 IS.I.OR.220

Vulnerability alerts

Known exploited vulnerabilities matched to your elements, and a decision recorded on each.

GM1 IS.I.OR.220: the discovery of an exploitable vulnerability is an information security event — detection includes vulnerability discovery, response includes vulnerability management (AMC1 IS.I.OR.220(b)).
Every day at 05:30 (Athens time) the CISA Known Exploited Vulnerabilities catalogue is downloaded and matched to the in-scope elements of every organisation; an element is matched again when its vendor, model or scope changes, and the managers can check on demand.
Conservative matching on vendor and product: the vendor must match, generic words never count, model codes must be of the same family. High confidence when the element's model or version names the product, medium otherwise — and held at medium for cloud and contracted services. The catalogue lists no affected versions, and the alert says so.
A new high-confidence alert on a safety-relevant or critical element is notified once to the posts the organisation names and its administrators. Entries added to the catalogue more than 24 months before the alert are listed apart and never notified — still exploited, mostly patched long ago.
Each alert dismissed with a reason — mitigated, not applicable, false match — on an append-only decision trail, or converted into a vulnerability event with the element and the awareness time filled in; reportability (AMC1 IS.I.OR.230(a)&(b), point (c)) is decided at triage.
EPSS scores from FIRST for the matched CVEs, links to the public records, and the catalogue version and date on the page. CISA KEV is the only feed.

Vulnerability alerts: the CISA Known Exploited Vulnerabilities catalogue version, how many elements were checked, counters for open, high-confidence and safety-relevant alerts, and the alerts with their CVE, element, match confidence, EPSS score, KEV due date and status. — Known exploited vulnerabilities matched to the elements register, each with its match confidence, EPSS score and the decision still to take.

IS.I.OR.205(a), (b)

Elements, interfaces and scope

What could be exposed to information security risks, and who you are exposed through.

An elements register: activities, services the organisation operates, provides, receives or maintains, facilities, resources, systems, equipment, data and information, and networks (205(a)(1)–(2)).
For each element: owner, an in-scope decision with its rationale, protection needs for confidentiality, integrity, availability and authenticity, criticality, whether it is managed internally or by a contractor, dependencies both ways, the recovery time and the detection coverage.
Typical elements added quickly from the aviation services examples of the AMC and GM appendices.
Parties — suppliers, service and cloud providers, customers, partners, authorities, design approval holders — with whether they are themselves subject to Part-IS and their security point of contact.
Interfaces (205(b)): the party, the data exchanged, the elements used, your role as producer, processor, dispatcher or consumer, the direction of exposure, and the risk information shared.
The ISMS scope statement with its inclusion and exclusion criteria, and the Appendix V proportionality self-assessment that records why your implementation corresponds to the nature and complexity of your activity (IS.I.OR.200(d)).

The elements register: counters for elements in scope, elements awaiting a scope decision and detection coverage, a prompt to decide the scope of two elements, and the elements with their scope, criticality, protection needs, owner, management and recovery time. — The elements register, with the elements still awaiting a scope decision and the safety-relevant ones the detection strategy does not cover.

IS.I.OR.205(c), (d)

Risk assessment

Threat scenarios, their level and their acceptability, reviewed when they should be.

A risk is a threat scenario: threat source, attack vector, exploited vulnerabilities, existing controls and the safety consequence. Templates from the example threat scenarios of the AMC and GM.
Every risk is associated with at least one element or interface, as IS.I.OR.205(c)(2) requires — the application will not save one without.
The acceptability matrix is the organisation's own, 3 to 5 levels per axis, with its methodology and acceptance criteria written down. The default is GM1 IS.I.OR.205(c): potential of occurrence Low, Medium, High against severity Low, Moderate, High, each cell acceptable, conditionally acceptable or not acceptable.
Likelihood can be scored the way the EASA G-04 guidelines describe: opportunity, preparation and execution, each from 1 to 3, with a one-line justification; a total of 3–4 is Low, 5–6 Medium, 7–9 High. On the default three-level scale the score proposes the level.
The GM1 guidance sits next to the pickers: protection, exposure reduction and attack attempt for likelihood; negligible effect, incident and unsafe condition for severity.
Inherent and residual ratings. Conditional acceptance only by the accountable manager or delegate, with its conditions, an expiry date and compensating monitoring — enforced by the security rules, not only on the screen.
Reviews on a period set by acceptability (AMC1 IS.I.OR.205(d); defaults 3, 6 and 12 months) and on the four triggers of 205(d): a change in the elements, in the interfaces or the risks communicated, in knowledge, or lessons from an incident. Each review records the owner's approval and rationale.
A heat map on the configured matrix, inherent or current; sequential references (RSK-001) and a full history.

The risk register: the heat map on the GM1 IS.I.OR.205(c) matrix, potential of occurrence against severity, beside counters for not acceptable and conditionally acceptable risks, decisions awaiting the accountable manager and overdue reviews and treatments. — The risk register on the default GM1 IS.I.OR.205(c) matrix, with the decisions waiting for the accountable manager.

IS.I.OR.210

Risk treatment and controls

Measures for every unacceptable risk, implemented in time and checked.

A treatment plan per unacceptable risk, with the options of IS.I.OR.210(a) — control the circumstances, reduce the consequences, avoid the risk — an objective, an owner and a timeline accepted by the accountable manager or delegate.
Implementation delays recorded with their cause and accepted by the accountable manager, optionally conditioned on compensating controls.
Confirmation that the measures introduce no new potential unacceptable risk, and an effectiveness check with the date of the next one.
Communication recorded (210(b)): to the accountable manager, the information security manager and affected staff, and to the interfacing organisations with which a risk is shared.
A controls register and statement of applicability that seeds from the 93 controls of ISO/IEC 27001:2022 Annex A, plus your own: applicability and justification, implementation status, owner, effectiveness and the risks each one treats.
Risk register as PDF and Excel, the risk treatment plan as PDF, the statement of applicability as PDF.

The treatment tab of a not acceptable risk: the IS.I.OR.210(a) treatment options chosen, the objective and means, the target date accepted by the accountable manager, and a completeness checklist of the treatment plan. — The treatment plan of a not acceptable risk: options, means, a timeline accepted by the accountable manager, and what the plan still lacks.

IS.I.OR.235, 215(c)

Suppliers and contracted activities

Contracted information security management activities under your oversight, and what your suppliers must report.

Contracts that separate contracted information security management activities, which IS.I.OR.235 governs, from operational services, whose risks go through 205 and 210.
A prior assessment of the contractor and an agreed risk assessment.
A clause checklist: the obligation to report information security events to you (215(c)), a point of contact, access for the competent authority to the contracted organisation (235(b)), audit rights, performance indicators and remediation.
Periodic contract reviews (every 12 months by default), supplier audits, the events a party reported, and retention for 5 years after the contract is amended or terminated (245(a)(3)).

The interfaces register: each interface with its party, the organisation's role as consumer, producer, processor or dispatcher, who originates the data, the exposure, whether risk information is shared, and its TLP marking. — Interfaces with suppliers and service providers: the organisation's role on each, the exposure, whether risk information is shared, and the TLP marking.

IS.I.OR.200(a)(6), (a)(7), (a)(12), 225

Compliance monitoring

Where you stand against every requirement, and what you are doing about the gaps.

A requirements matrix with one row per Part-IS requirement: status, how you comply, the ISMM cross-reference, evidence, owner and when it was last assessed.
Each row carries the implementation level of the EASA G-03 guidelines — Present, Suitable, Operating, Effective — the grades for ISMM review and audit, the internal procedure reference and the corrective action plan reference.
The compliance monitoring report as PDF and Excel, in the columns authorities ask for: requirement, ISMM reference, procedure reference, review and audit grades, PSOE level, corrective action plan.
Audits of three kinds — internal compliance monitoring, supplier (235) and authority oversight — with Part-IS checklists, including one built on the G-03 oversight checklist.
Findings with Level 1, Level 2 and observation deadlines (30, 90 and 180 days by default); authority findings with the authority's level and reference, the agreed period, root cause, corrective action plan and the correction accepted by the authority (IS.I.OR.225).
Directives: measures notified by the competent authority as an immediate reaction to an incident or vulnerability (200(a)(6)), with implementation, evidence and confirmation to the authority.
A summary for the accountable manager, because 200(a)(12) asks for feedback on findings to reach them.

Compliance monitoring: counters for requirements compliant and assessed, open findings and authority measures, and the progress of each IS.I.OR point with its compliant and assessed share and its PSOE maturity. — Progress per IS.I.OR point: the share compliant, the share assessed, and the PSOE maturity recorded against each.

IS.I.OR.200(e)

Derogation

The application to be exempted from the ISMS requirements, and what it leaves in place.

An application built with the content the EASA derogation guidelines list: the affected approvals, focal point, justification and time frame, services provided and received, an overview of the information systems, the summary of the risk assessment, the methodology, the people involved, attachments and mitigating measures.
Prefilled where the registers already hold the answer — services from the elements, the architecture from the systems, the risk summary from the risk register, the participants from the appointments.
Signed by the accountable manager, with the submission, the decision, the authority's reference and the periodic review of its continued validity.
The reminder of what still applies after a derogation: Regulation (EU) No 376/2014 reporting and the confidentiality of information received from other organisations (200(a)(13)).

IS.I.OR.240, 245(b)

People, acknowledgements and trustworthiness

Who is accountable, who is competent, and proof that each person accepted their role.

Appointments: the accountable manager (and the CEO), the person or group of IS.I.OR.240(b) with their deputies, compliance monitoring (240(c)), the common responsible person (240(d)) and key persons — each with duties, accountabilities, responsibilities and authorities.
An organisation chart drawn from who reports to whom, as IS.I.OR.250(a)(7) asks the ISMM to show.
A catalogue of information security roles with their required competences, adapted from the European Cybersecurity Skills Framework profiles in the AMC and GM appendices.
Acknowledgement in the application: the assignee accepts their role, and the record keeps who, when and the text they accepted (240(h)). Only the assignee can acknowledge.
Personnel records: qualifications, experience and competence against the role, with the gaps (240(g)); identity verified on documentary evidence and the trustworthiness check with its method, result and recheck date — every 60 months by default (240(i)) — visible only to the information security manager and administrators.
A member reads their own record and gets a copy (245(b)(2)); the record is kept for 3 years after the person leaves (245(b)(1)).
Training records with expiry and a 60-day warning, including the accountable manager's basic understanding of the regulation (240(a)(3)); awareness notices acknowledged per person and reminded after 7 days; the staffing statement of 240(f).

The role catalogue with its ECSF profiles, the roles that need a trustworthiness check, and who has acknowledged what.

IS.I.OR.250, 200(a)(1), 200(c)

ISMM, policy and documents

The manual, the policy and the controlled documents the ISMS is described in.

An ISMM builder with the 10 sections of IS.I.OR.250(a) plus your own, each written in the application or pointing to a controlled document (GM1 IS.I.OR.250(a)), with guidance per section and a completeness check.
Sections generated from the registers you already keep: the appointments for (2), (3), (6) and (7), the policy for (4), the staffing statement for (5).
The accountable manager's statement signed in the application, countersigned by the CEO when the accountable manager is not the CEO (250(a)(1)).
Revisions under your amendment procedure (250(c)): what changed, whether the competent authority must approve it, when it was sent and when it was approved.
Declared-organisation mode (Reg. (EU) 2025/2293): no approval step for the initial issue, amendments or changes; the copy sent to the authority is still recorded.
A cross-reference to Annex II for an ISMM integrated into another manual or exposition (250(d)), and the ISMM as PDF with its cover, statement, contents and sections.
The information security policy checked against points (a) to (j) of AMC1 IS.I.OR.200(a)(1), endorsed by the accountable manager, and published as a notice that every member acknowledges.
A register of controlled documents — procedures, the risk methodology, the incident response and recovery plans, the vulnerability management and detection strategies, the retention policy — with or without the file, files up to 25 MB.

The ISMM builder: manual completeness, sections complete, the signed accountable manager statement and the revision in force, above the contents of IS.I.OR.250(a) with each section's status and completeness. — The ISMM builder: the contents of IS.I.OR.250(a), each section's status, and the signed statement of the accountable manager.

IS.I.OR.255, 210, 225, 260(b)

Changes and actions

Changes to the ISMS handled the way your procedure says, and one tracker for everything you have undertaken to do.

Change records by the types of GM2 IS.I.OR.255, with a guided route: covered by your approved change procedure (notified on implementation), needing prior approval (255(b)), or without impact on the ISMS.
The content AMC1 IS.I.OR.255 asks for: nature and purpose, implementation plan, verification plan and potential impact on aviation safety — and the risks the change raises.
The application to the competent authority and its approval before implementation, bypassed for declared organisations, which may implement immediately; the link to the ISMM amendment the change requires.
Approval of a change restricted to an administrator or the accountable manager, in the security rules.
Every treatment, corrective, preventive and improvement action in one tracker — whatever raised it: an event, a risk, a finding, a directive, a change, a contract, a management review or a maturity assessment — with an owner and their post, a due date and verification of effectiveness.
Actions routed to a post by area, notified on assignment and 7 days before they are due, and visible to the person who has to do them, whatever their role.

Changes to the ISMS: counters for open changes, decisions awaiting the accountable manager and authority notifications due, and the register with each change's route under IS.I.OR.255, status, authority step, planned date, actions and review date. — Changes to the ISMS, each on its IS.I.OR.255 route — within the approved procedure or needing prior approval — with the authority step it still needs.

IS.I.OR.260

Continuous improvement

The effectiveness and maturity of the ISMS, assessed with indicators.

Performance indicators covering the areas GM1 IS.I.OR.260(a) names — risk assessment and treatment, non-conformities and corrective actions, incidents and vulnerabilities, personnel competence — computed from the registers or entered by hand.
Each indicator with its description, objective, reference value, target, collection method, frequency, who collects it and who reviews it; monthly measurements and a trend.
Maturity assessments on a five-level model mapped as GM1 IS.I.OR.260(a) does, or on the G-03 PSOE scale, per ISMS process, with current and target levels, justification, evidence and improvement actions. No specific maturity level is required by EASA; higher maturity can matter for oversight.
Management reviews chaired by the accountable manager: inputs summarised from the registers, decisions, revised objectives, and the actions they raise.

Performance indicators: the four areas GM1 IS.I.OR.260(a) asks to monitor, counters for indicators on target, warning and alert, and each indicator with its current value, target and alert levels, status and trend. — Indicators in the four areas GM1 IS.I.OR.260(a) asks to monitor, each with its target, alert level and trend.

IS.I.OR.245

Dashboard, records and reports

What is open and what is due, and everything the authority asks for as a file.

The information security manager's view: events by stage, running 72-hour clocks, unacceptable and conditionally acceptable risks, overdue treatments and reviews, open findings and directives, compliance and maturity, indicators against target, open vulnerability alerts.
A Part-IS readiness view of the four items the G-03 guidelines ask organisations to make available: the ISMM, the change procedure, the initial risk assessment and compliance monitoring evidence with a corrective action plan.
Every member's own view: a button to report an event, their reports, their actions, and what they still have to acknowledge.
Retention per IS.I.OR.245, archive instead of delete, and a history on every record written by server-side functions.
The audit pack for the competent authority as PDF, and one Excel workbook of every register.

The AviIS dashboard of a demonstration operator: counters for open events, running IS.I.OR.230 clocks, not acceptable risks, overdue treatments and reviews, open findings, authority measures, Part-IS compliance and ISMS maturity, above the decisions waiting for the information security manager and the notices to acknowledge. — The information security manager's dashboard: what is open, what is due, and what waits for a decision.

Roles, and the posts beside them

A user belongs to exactly one organisation. Their role travels on the sign-in token as a claim set only by a server-side function, and the security rules enforce it on every read and write — the browser is never trusted.

Roles, and the posts beside them
Role	What they can do
Administrator	Everything, including users, invitations and settings.
Information security manager	The person or group of IS.I.OR.240(b): events, external reporting, risks, scope, suppliers, compliance, people, documents, improvement and reports; settings, users and the audit log read-only.
Auditor	Compliance monitoring (200(a)(12)): audits and findings in full; creates and updates actions but does not verify them; reads everything else, including settings, users and the audit log.
Reporter	Every member of staff: reports events and follows their own, reads documents, notices and their own personnel record, acknowledges the policy and their roles, progresses their own actions.
Viewer	Read-only across the organisation; no users, settings or audit log.

A person also has a post — the management posts (Accountable Manager, CEO, Information Security Manager and deputy, Compliance Monitoring Manager, common responsible person, IT Manager, Safety Manager, Aviation Security Manager, nominated persons, CAMO and maintenance managers, Head of Training, DPO) or a staff post (IT staff, SOC analyst, flight crew, engineer, dispatcher, contractor…). The role decides access. The post decides routing: who is told about a new event, who is pre-filled as the owner of an action, who may conditionally accept a risk, approve a change or sign the ISMM statement, who confirms a training record. Records marked TLP:AMBER+STRICT or TLP:RED are readable only by the information security manager, administrators and the named need-to-know list.

Every export

Each one is generated from the organisation's live data, with the organisation's name and logo.

Every export
What	Format	Notes
Notification, report, follow-up	PDF, email draft	Per IS.I.OR.230(c) stage and recipient, with the TLP marking and the point of contact.
Event for ECCAIRS 2	E5X	Occurrence category ISEC, taxonomy version recorded (default 7.1.0.0).
Risk register	PDF, Excel	Threat scenarios, associated elements and interfaces, ratings, acceptability, treatment.
Risk treatment plan	PDF	Measures, owners, timeline, acceptance and effectiveness checks.
Statement of applicability	PDF	ISO/IEC 27001:2022 Annex A and your own controls, with justification and status.
Elements register	PDF, Excel	Elements, interfaces and parties.
Compliance monitoring report	PDF, Excel	Every requirement with ISMM and procedure references, grades, PSOE level and corrective action plan.
Audit checklist and findings	PDF	A completed checklist with answers and evidence; findings with levels and deadlines.
ISMM	PDF	Cover, signed statement, contents, sections and the cross-reference to Annex II.
Information security policy	PDF	The endorsed policy.
Personnel record	PDF	The copy a member is entitled to (IS.I.OR.245(b)(2)).
Change record	PDF	The change, its route, assessment, approvals and review.
Management review, maturity assessment	PDF	Minutes with decisions and actions; the assessment with current and target levels.
Audit pack	PDF	Cover, indicators, breakdowns, high and critical events in detail, audit log and compliance statement.
Organisation workbook	Excel	Every register on its own sheet.

What is not built

Said plainly, so nobody finds out during an audit.

No transmission to any authority. AviIS produces the PDFs, the email drafts and the E5X file; you submit them through the channel your competent authority defines and record the submission. There is no machine-to-machine link to ECCAIRS 2 or to any national portal.
No detection tooling. AviIS records what your detection measures find and what you did about it (IS.I.OR.220); it is not a SIEM, it reads no logs, scans nothing and watches no network. Its one external feed is the CISA Known Exploited Vulnerabilities catalogue, matched to the elements you register — no NVD, EUVD or CSAF feed.
Part-IS.I.OR only. The Part-IS.D.OR variant of Delegated Regulation (EU) 2022/1645 — design and production organisations, aerodrome operators, apron management — is not modelled, and nor is anything on the authority side (Part-IS.AR).
No native mobile app. The web application is responsive and works on a phone, but there is no App Store or Play Store listing.
No public API. Data leaves through the exports above.
English only.
The AI assistant drafts and suggests; it decides nothing, sends nothing to an authority and writes nothing until a person accepts it.

See it with your own organisation.

Create your organisation at app.aviis.aero and you are its first administrator. Record your approvals, and every module above is there.

Create your organisation Read Part-IS explained