A gap analysis is a bounded piece of work with one purpose: to establish, before money is committed to anything larger, where your current CORSIA position falls short of what verification will test.
It is the engagement that should come first, and the one most often skipped in favour of starting the visible work.
Why It Comes First
Most CORSIA problems are discovered at verification, a year after the decision that caused them, when the reporting year is closed and the data cannot be recreated.
A gap analysis moves that discovery forward to a point where it is still cheap to act on. It is diagnostic rather than corrective — the output is a prioritised list of what needs fixing and what it will take, not the fix itself.
The test of a good one: it should be capable of concluding that you are in reasonable shape and need less work than you expected. An assessment that always recommends a large follow-on engagement is a sales process, not a diagnostic.
The Eight Areas
1. Scope determination
The question: Is the in-scope determination documented and defensible?
Recurring gap: Group entity structure unresolved. An operator with several Air Operator Certificates has several CORSIA operators, each with its own threshold test and reporting obligation. Aggregating at group level produces a report the authority will reject.
Also common: wet lease and code share arrangements where nobody has established which certificate the flight was conducted under.
2. Monitoring plan
The question: Does actual practice match the approved plan?
Recurring gap: Drift. The plan says one thing; the team has been doing something slightly different for eighteen months because a system changed or a person left. Verification tests reporting against the plan in force during the period, so drift produces non-conformities even where the underlying data is fine.
Also check that plan versions are retained with their approval dates. If the plan was revised mid-year, both versions matter.
3. Data sources
The question: Is exactly one system authoritative for each reported field?
Recurring gap: Two sources, no rule. Fuel uplift dockets say one thing, the finance system another, and which one is used depends on who prepared the figure that month. This is not a data problem so much as a governance one, and it is entirely fixable by decision.
4. Reconciliation
The question: Are the rules for resolving discrepancies written down?
Recurring gap: Decided case by case. Sources will disagree — that is normal and expected. What verification probes is whether the resolution is consistent and defensible. "That is what we have always done" is not an answer that survives.
This is frequently the largest single gap, and it costs nothing but time to close.
5. Data gaps
The question: Is the fill procedure defined in advance?
Recurring gap: Invented after the gap appears. A documented estimation method applied consistently is defensible. An ad hoc estimate devised once a gap is noticed is not, even if the number is identical.
6. Fuels claim
The question: If CORSIA Eligible Fuels are claimed, is the chain of custody evidenced?
Recurring gap: Fuel bought, paperwork missing. Qualifying fuel with no approved-scheme certification and no chain-of-custody documentation produces an environmental benefit and no CORSIA claim. Operators who budgeted on the reduction discover the disallowance at verification.
7. Records and knowledge
The question: Could someone not involved reconstruct a reported figure from the files alone, three years from now?
Recurring gap: Knowledge held by one person. The reconciliation logic lives in someone's head, the source system has been replaced, and the person has moved on. This is the gap that turns a routine audit into a serious problem.
8. Registry readiness
The question: Are accounts open, with more than one authorised representative, and tested?
Recurring gap: Left until purchase time. Account opening involves know-your-customer processes and takes four to eight weeks. Agreeing a purchase and then starting onboarding means your own compliance blocks delivery.
What the Output Should Contain
A useful gap analysis produces more than a list of findings:
| Element | Why |
|---|---|
| Finding, per area | What is actually wrong |
| Severity | Would this cause a verification finding, and how serious |
| Evidence | What was examined to reach the conclusion |
| Effort to close | Days, not adjectives |
| Sequence | What must be fixed before something else can be |
| What is already fine | So effort is not wasted re-doing sound work |
That last row matters. An assessment listing only problems gives no sense of proportion and invites over-investment in areas that were already adequate.
Scaling It
A small operator near the threshold may need little more than a scope determination and a data readiness test — a few days of work with a clear yes or no at the end.
An established operator preparing for a first verification needs all eight areas examined, with sampling of actual records rather than review of documented process alone.
An operator with a previous verification finding should focus the analysis on the finding's root cause rather than repeating a general review. A repeat finding is treated far more seriously than a first one.
Sampling Actual Records
The difference between a useful gap analysis and a superficial one is whether it examines records or only process documents.
Reviewing the monitoring plan tells you what should happen. Sampling twenty actual flights and tracing each reported figure back to its source tells you what does happen, and the two diverge more often than anyone expects.
A practical sampling approach:
Trace end to end, both directions. Pick reported values and work back to source records; then pick source records and confirm they reached the report. The second direction catches completeness problems that the first cannot — a flight missing from the report will never be sampled from the report.
Choose awkward cases deliberately. A diverted flight, an outstation uplift, a charter, a month with a system outage, a date near a plan revision. Sampling only routine flights tests only the part that was always going to work.
Check the discrepancy cases. Where sources disagreed, was the documented rule applied, and is the decision recorded?
Test the reconstruction claim. Hand a sampled figure to someone uninvolved and ask them to explain it from the files alone. If they cannot, neither will a verifier.
Twenty well-chosen records reveal more than a full document review, and take less time.
When to Run One
Before the first monitoring plan, to establish what your data can actually support.
Before the first verification, to find what the verifier will find while there is still time.
After any significant change — a system replacement, a fleet or network change, a group restructure, a key person leaving.
After a verification finding, targeting the cause rather than the symptom.
Before the second phase, because route coverage expands from 2027 and the scope determination needs re-running against the new participation position.
Turning Findings Into a Plan
A list of gaps is only useful if it converts into sequenced work. Three principles make that conversion reliable.
Sequence by dependency, not by severity. Some fixes block others. There is no point designing reconciliation rules before the authoritative source for each field has been decided, and no point writing a monitoring plan before the scope determination is settled. A severity-ordered list that ignores dependency produces rework.
Separate what must precede the reporting year. Anything affecting the monitoring plan has a hard deadline, because the plan must be approved before the year it covers. Everything else can follow. Splitting the list on that boundary immediately clarifies what is urgent.
Size the effort honestly, in days. "Improve documentation" is not a plan. "Two days to write reconciliation rules for the six known discrepancy types, one day to review with flight operations" is. Vague effort estimates are how remediation plans quietly fail to happen.
A practical output format is a single table with finding, severity, dependency, owner, effort and deadline. It fits on a page, it can be taken to a management meeting, and progress against it is visible without a status report.
Re-run the analysis after remediation, at least on the areas that were failing. Closing a gap on paper and closing it in practice are different, and the difference surfaces at verification if nobody checks.
Frequently Asked Questions
How long does a gap analysis take? For a small operator, days. For an established carrier with multiple entities, two to four weeks including record sampling.
Can we do it ourselves? Partly. Internal review catches known problems. An external view is more likely to find what has become invisible through familiarity, and knows what verifiers actually test.
Is it the same as a readiness assessment? Broadly similar terms. Both examine current position against requirements. See the CORSIA readiness assessment checklist.
Will it tell us our verification will pass? No, and be sceptical of anyone claiming otherwise. It identifies gaps against what verification tests; the verifier reaches their own opinion independently.
What if it finds serious problems? Better now than at verification. Prioritise by severity and by what blocks other work, and fix in sequence.
Should the same firm fix what it finds? Common and often sensible, but agree the remediation scope separately so the diagnostic is not shaped by the size of the follow-on work.
How much does a gap analysis cost relative to the remediation? A small fraction. That asymmetry is the argument for doing it — it is cheap insurance against committing budget to the wrong work, or against discovering a structural problem at verification.
Can it be run remotely? Largely yes. Document review, data sampling and interviews work remotely. A site visit adds most where the question concerns how records are actually created at stations.
What comes next? Usually the monitoring plan or its revision, then the data pipeline. See your first year of CORSIA compliance.
Working out what CORSIA means for your operation? DSTechnoverse provides CORSIA carbon credit services for Indian operators and project developers — scope assessment, monitoring plans, data pipelines, verification support and unit sourcing. We are based in Indore, Madhya Pradesh and work across India.
Apply as a CORSIA buyer or seller
Talk to our carbon markets team about your position.
