A known consignor needs a deadline register, not another spreadsheet. Here is why. A known consignor holds a facility approval. With an expiry date. Its security officer holds a reliability check. Also with a date. Every trained employee holds a training certificate. Also dated. Every carrier picking up cargo signs a security declaration. Tied to a route. Four documents. Four issuers. Four rhythms. They almost never expire on the same day. That is what makes tracking hard. In practice it lands in a spreadsheet. Updated once a year. Right before the inspection.
My position: the single deadline is not the problem. Five years here, five years there, a person can hold that. The problem is the mix. Many people. Several partners. Several deadline types at once. A deadline register, call it the KC register, solves that. It is easier to build than it looks.
Regulation (EU) 2015/1998 covers chapter 6 of its annex. Cargo and mail. A company becomes a known consignor once the aviation security authority grants approval. That approval runs for up to five years. So say consistent secondary sources on the annex. Then it needs renewal. The regulated agent carries a similar, time-limited role. Toward the same authority. Both need a security programme. And a named security officer, call them the SO.
For the SO personally, a second and separate deadline applies. The reliability check under section 7 of the German Aviation Security Act. Known as LuftSiG. The rule on these checks, the LuftSiZÜV, sets it out in section 3 paragraph 5. A positive result is valid for five years. Counted from the notice of the last result. File the renewal request early, at least three months ahead, and the SO stays cleared. Until the new check finishes. Three months is not much slack. Not if the deadline only shows up on the day itself.
Then there is training. Chapter 11 of the annex requires initial training. And refresher training after that. For the SO role, item 11.2.5, training providers cite a five-year refresher cycle. Ten teaching units, since 2024. Germany's Federal Aviation Office states a general rule too. Refresher training at least once every five years. With its own absence rule. Away from the role more than six months, and the SO counts as no longer qualified.
Five years. Five years. Five years. Sounds like one deadline. It is not. The start dates differ. The approval date of the facility. Each person's own check date. Each employee's own training date. Twenty people in the security area, and that becomes forty to sixty separate dates. Fast. More than anyone holds in their head.
The carrier's security declaration has its own form under the annex. It carries no fixed expiry the way the check or the approval do. It states one thing: cargo on this trip was, and will be, handled securely. In practice it is issued per partner. Often per contract. It needs renewal whenever the route, the vehicle or the partner changes.
That is why a KC register cannot treat it like the other three deadlines. It has no clock built into the regulation. It needs its own rule instead. An expiry the partner sets. Or a follow-up interval when the partner sets none. A register that tracks only the three statutory deadlines misses the one document that changes the most.
We already build data reconciliation and automation for forwarders. For companies running several systems and several partners. The register fits the same pattern. Four sources. One row per record. One alert.
First, the staff list. Name, role, security function, start and end date. Second, the training certificate. Almost always a PDF with a date. An agent reads name, course and date. Instead of someone retyping it. Here sits the most common error. A misread date is worse than no date at all. It claims security where there is none. So every value runs through a check first. Future date. Certificate older than five years. Unknown course type. Each case lands on a review list. Not straight in the register. Third, the check notice from the authority. Same intake. Fourth, the security declaration per partner. With its own rule from above.
The four sources become one row per record. Person or partner, record type, start date, expiry date, source file. The expiry alert fires with lead time. Not on the day itself. Ninety days before the check, since the renewal already needs three months' notice. Sixty days before training. Six months before the approval. Every alert carries a status. Open. Booked. Resolved. An alert does not vanish by itself. Someone has to clear it. That is the difference between a register and a reminder buried in an inbox.
More interesting than the register itself is the link to physical access. Access to the warehouse zone or the cargo desk runs through a badge or code system. That system already exists. It usually asks one thing: is the badge active? It does not ask whether the person's record is still valid.
That second question can be wired in. The register holds the status of all four records per person. If one expires without a logged renewal, the register blocks that access. Not the badge system itself. Not on the expiry day itself, without warning. After the last unacknowledged alert. Same mechanism as customer portal access under ISO 27001. There, rights on portals outside the company AD. Here, physical aviation-security zones. Same root cause both times. The record lives outside the system that decides on access. The register approach for AEO runs a similar logic toward customs. Different legal basis. Different declaration. For aviation cargo, tying it to physical access is the extra step. It prevents something. It does not just log it.
Inspection day changes the most. Instead of four binders and a spreadsheet search, the SO shows one export. Every person. Every record. Every date. Every status. The inspector sees at a glance which record sits close to expiry. And whether a renewal date is booked already.
For the cargo desk, the daily case changes more than the exception does. A new hire gets no access until training, and a check where needed, both show as valid. No more access granted on a phone call to whoever runs the badge system.
For the SO, their own deadline changes least. They already track it. What changes is visibility into the other twenty people. Checked once a year before, at best.
Three honest limits. First, not every training provider issues a readable PDF. Some certificates arrive as a photo. Or a poor scan. Then date extraction stays uncertain. The case moves to the review list, not straight into the register. Second, not every partner issues a security declaration with a clear expiry. Some run informally for years. Then only the internal interval remains. An estimate, not a guarantee. Third, and this is the limit that matters most: a person may keep working briefly despite an expiring check. Or a facility approval may get extended in a borderline case. That call stays with the SO. And the authority. The register gives the basis for it. It does not make the call.
A staff list with the security role marked. An agent that reads certificates and check notices as PDFs, and pulls the date. Checked against a plausibility rule. A rule for the security declaration per partner. An expiry alert with staged lead time and a status. A link to the badge system that locks on an unacknowledged alert. An export for the inspection. None of this is exotic. Every piece already exists somewhere in every facility we know. What is new: they run together, in one register.
How many separate expiry dates run in your facility right now? Without anyone seeing them all on one page? Send me the number. I will compare it against other aviation cargo facilities.
