Key takeaways
- Security needs one named owner with authority, even part-time. Without that, every other step stalls.
- Your most valuable assets are design data, flight-test data and source code. Most start-ups protect their email better than their CAD vault.
- A risk register with ten honest rows beats a policy binder nobody reads. Investors and certification authorities both respond better to the register.
- The first 30 days are about accounts and backups, the next 30 about the engineering environment, the last 30 about evidence you can show to others.
- Do the company and the product together: a good organizational program makes the DO-326A evidence easier, and vice versa.
Day 0: decide who owns it
In a company of ten to fifty people there is no security department, and there does not need to be one. There does need to be one person whose name is on the risk register and who can say no to a shortcut. Usually that is the CTO or the head of engineering, occasionally the COO. Give them a written mandate of two paragraphs, a budget line even if it is small, and a slot on the leadership agenda once a month.
Then write the risk appetite in one sentence. Something like: "We will not accept risks that could compromise the safety of the aircraft, disclose design data to a competitor, or stop the company from operating for more than two days." Everything you prioritize afterwards flows from that sentence, and it is the first thing a certification authority or a due-diligence team will ask to see, in some form.
Days 1–30: know what you have and lock the doors
Inventory the assets that matter
You cannot protect what you have not listed. For an aviation start-up the list is short and specific:
- Design data: CAD models, structural and aerodynamic analyses, electrical schematics, the requirements database, the certification plan.
- Software: flight-control and ground-station source code, build systems, simulation environments, the repositories and the accounts that can push to them.
- Test data: flight-test logs, telemetry, bench-test results, and the tools that produce them. This data is both commercially sensitive and certification evidence.
- Corporate systems: email, documents, finance, HR, the cloud consoles that host everything above.
- Prototype systems: the aircraft and ground stations themselves, their debug ports and update paths.
- People and access: who holds which accounts, with what privileges, and which contractors and partners have access to what.
Put this in a spreadsheet with an owner and a sensitivity rating per row. It will become the backbone of your risk register and, later, of your DO-326A security scope.
Fix the account layer
Almost every breach of a small company starts with an account. In the first 30 days: multi-factor authentication on every cloud console, code repository, email account and VPN, with no exceptions for founders; a password manager for the team; removal of shared credentials; a review of who has administrator rights on what; and a documented joiner-leaver process so that access is removed on the day a person or contractor leaves. This is unglamorous and it removes most of the risk.
Make backups you have actually restored
Ransomware is a backup problem before it is anything else. Ensure design repositories, test data and corporate documents are backed up to a location the attacker cannot reach with the same credentials (offline or immutable storage), and restore something from that backup once so you know it works. Write down how long a full restore takes; that number belongs in your risk appetite sentence.
Days 31–60: protect the engineering environment
Segment what matters
The workshop Wi-Fi that a visitor's phone joins should not reach the flight-control build server. Separate guest, corporate and engineering networks, and keep prototype aircraft and ground stations on a network of their own. This costs a few hours of configuration on equipment you already have.
Control the paths to the aircraft
Decide now how software gets onto the aircraft and the ground station, who can do it, and how you know what version is flying. Signed builds, a release log and a rule that only named engineers load flight software are inexpensive today and expensive to retrofit after the architecture is frozen. The certification process will ask exactly these questions; see the airworthiness security guide.
Know your components
Build a bill of materials for software as well as hardware: the autopilot firmware, the open-source flight stack, the radio modules and their firmware, the libraries in your ground software. Subscribe to vulnerability notices for the important ones. When a partner or an authority asks "do you use component X, and did you patch it?", you want the answer in a table, not in someone's memory.
Protect the crown jewels specifically
Design and test data deserve controls that email does not: access limited to the people who need it, logging of who exported what, watermarking or at least version control on external shares, and contracts with suppliers and test partners that say who owns the data and how it is returned. Industrial espionage against aerospace start-ups is not hypothetical; the design data is the company.
Days 61–90: build the evidence others will ask for
The risk register
Ten to twenty rows, each with a plain-language risk, the asset it threatens, likelihood and impact on a simple scale, what you are doing about it, and who owns it. Review it monthly. Investors like it because it shows judgment; certification authorities like it because it is the seed of the security risk assessment they will want later. A template I use has these columns: Risk · Asset · Threat source · Likelihood (1–3) · Impact (1–3) · Current control · Planned action · Owner · Review date.
Five short policies, not fifty
Acceptable use, access control, backup and recovery, incident response (one page; see the incident response guide), and secure development for flight software. Each a page or two, written in your own words, signed off by the leadership. Nobody reads a fifty-page policy set, and an auditor can tell.
Answer the questionnaires before they arrive
Three groups will ask you about security, and they ask predictable questions.
| Who | What they ask | What satisfies them at this stage |
|---|---|---|
| Investors and their due-diligence teams | Who owns security; what would a breach cost; is IP protected; is there insurance; have you had incidents. | The named owner, the risk register, the backup test, evidence of MFA and access reviews, a one-page incident plan. |
| OEM partners and enterprise customers | A security questionnaire, often modelled on ISO 27001 or NIST CSF, asking about policies, access control, encryption, vulnerability management and incident handling. | Describe your program in NIST CSF 2.0 terms; map your five policies and controls to it. ISO 27001 certification only if the contract requires it. |
| Certification authorities | How the aircraft's systems resist deliberate attack; who is responsible; how updates and events are handled after delivery. | A draft Plan for Security Aspects of Certification, a system boundary diagram, and a first list of threat conditions with severities. |
The 90-day roadmap on one page
| By day | Governance | Company systems | Engineering and product |
|---|---|---|---|
| 30 | Named owner, mandate, risk-appetite sentence | Asset inventory; MFA everywhere; password manager; admin review; joiner-leaver process; backups restored once | Inventory of prototypes, ground stations and their access paths |
| 60 | Monthly security slot on the leadership agenda | Network segmentation; endpoint protection and patching on all laptops; email filtering | Signed builds and release log; software bill of materials; access controls and logging on design and test data |
| 90 | Risk register reviewed; five policies signed | Incident plan rehearsed once; partner questionnaire answers drafted | Draft PSecAC, system boundary diagram, first threat-condition list; supplier data clauses in contracts |
None of this requires new hires or expensive tools. It requires decisions, a few weekends of configuration, and the discipline to keep the register current. After 90 days you will have a program that a partner, an investor or an authority can inspect, and a foundation that ISO 27001 or EASA Part-IS can be built on when a contract or an approval demands it.
Questions I get asked
Who should own security in a ten-person company?
One named person with authority, usually the CTO or the head of engineering, with a two-paragraph mandate, a budget line and a monthly slot on the leadership agenda. A part-time owner with authority beats a full-time hire without it.
What should we protect first?
Accounts and backups. Multi-factor authentication everywhere, a password manager, removal of shared credentials, and backups of design and test data that you have actually restored once. Those steps remove most of the risk in the first 30 days.
What will investors and certification authorities ask?
Investors ask who owns security, what a breach would cost, whether the IP is protected and whether you have had incidents; a risk register and a backup test answer most of it. Authorities ask how the aircraft resists deliberate attack and who is responsible; a draft Plan for Security Aspects of Certification and a system boundary diagram is the right first answer.
Do we need ISO 27001?
Not in the first 90 days. Describe your program in NIST CSF 2.0 terms and map your five policies to it; pursue ISO 27001 certification when a contract requires it.
How I can help
My security program and readiness assessment compresses this into two to three weeks: I review your systems, people and obligations against the framework that fits you, and you get a prioritized risk register and a 90-day roadmap your own team can run. If you are designing an aircraft, I can run the product-side threat model in parallel.
Ask about a readiness assessment
Founder of Mevocopter Aerospace. Worked in network security before aviation, built several companies in Canada, and led the concept design of a hybrid eVTOL air ambulance. Publications · ORCID
References
- Center for Internet Security. CIS Critical Security Controls v8.1, Implementation Group 1.
- NIST (2024). The NIST Cybersecurity Framework (CSF) 2.0, and the CSF 2.0 Small Business Quick-Start Guide.
- NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments.
- RTCA DO-326A / EUROCAE ED-202A, Airworthiness Security Process Specification.