Why we built a three-layer authorization system across nine countries — and why a verified identity doesn't automatically justify access to someone's personal data.
We could verify that someone was a legitimate investigator. We still couldn't assume they had the right to use a particular person's data.
That distinction changed how we designed one of the most important parts of Axon OSINT.
At first, the challenge seemed straightforward.
We were building a digital investigation platform. We needed a way to distinguish professional investigators and legitimate organizations from ordinary account holders.
A familiar verification workflow seemed reasonable:
- Collect professional credentials.
- Check the applicant's identity and organization.
- Approve or reject the application.
But then the questions became more difficult.
What if a licensed investigator applies from a country where professional requirements differ by region?
What if a company exists in an official business register but has no authority to conduct regulated investigations?
What if a government employee has a valid institutional identity but is acting outside an authorized mandate?
And here's the question that changed our architecture:
If we verify an investigator today, does that verification give them a legitimate reason to access every fraud report submitted tomorrow?
Of course not.
Identity, professional eligibility, access rights, and the lawful use of personal data are related questions.
But they are not the same question.
This is the story of how we approached that problem while building Axon OSINT.
1. The First Mistake Would Have Been Treating Verification as a Boolean
A typical application might have a database field like:
type User = {
id: string;
isVerified: boolean;
};
It's simple.
It's convenient.
And for some products, it may be sufficient.
But for a platform dealing with potentially sensitive investigation records, it leaves too many questions unanswered.
Verified as what?
An independent investigator?
An employee of a licensed investigation agency?
A representative of a registered organization?
An authorized government officer?
And verified under which jurisdiction's requirements?
A single Boolean can't communicate those distinctions.
So we treated professional verification as an application and decision process, not merely an account attribute.
Applicants provide relevant information and evidence. Requirements are resolved according to the applicable professional route. Reviewers evaluate that evidence. A final decision is recorded.
An applicant who passes verification has established a particular professional or organizational eligibility.
They have not received unlimited authority to process other people's personal information.
That became our first architectural boundary.
2. Nine Countries Meant More Than Nine Different Forms
Axon OSINT's verification architecture supports a launch baseline covering:
- 🇬🇧 United Kingdom
- 🇺🇸 United States
- 🇦🇺 Australia
- 🇩🇪 Germany
- 🇪🇸 Spain
- 🇫🇷 France
- 🇮🇹 Italy
- 🇵🇱 Poland
- 🇺🇦 Ukraine
The difficult part wasn't translating the application form.
It was determining what the application should require.
Professional licensing and authorization are not uniform.
The 🇺🇸 United States is a particularly clear example. Requirements for private investigators can vary substantially among states, and some jurisdictions do not impose statewide investigator licensing in the same way as others.
🇦🇺 Australia also requires attention to state and territory distinctions.
🇪🇺 European jurisdictions share important data-protection rules under GDPR, but professional regulation and national rules affecting investigations can differ.
We needed a way to represent those variations without reducing everything to a universal document checklist.
Our approach was to create jurisdiction-aware professional requirement routes.
A route considers factors such as:
- Country and applicable subdivision.
- Whether the applicant is an individual or an organization.
- Professional or organizational category.
- Applicable credentials, registration evidence, and mandate requirements.
- Relevant authoritative legal and regulatory sources.
In our documented production baseline, this resulted in 216 active professional and government verification routes: 141 personal routes and 75 organization routes.
These aren't 216 separate websites or manually designed registration pages.
They represent different combinations of eligibility requirements and jurisdictional rules.
And importantly, a registry result is only evidence.
It is not automatic professional approval.
3. A Registered Business Isn't Necessarily an Authorized Investigation Business
Imagine someone applies on behalf of an organization.
The organization appears in an official company register.
Its name matches.
Its registration appears valid.
Is that enough?
No.
A business register may establish that a legal entity exists.
It does not necessarily demonstrate that the business holds every professional authorization required for a particular activity.
Likewise, possession of a company email address doesn't automatically prove that the applicant can represent the company for investigation-related purposes.
We needed to distinguish several facts that are often incorrectly combined:
Legal existence: Does the organization exist?
Professional status: Does the applicable route require a licence, professional registration, or other evidence?
Representative authority: Is this person authorized to act for the organization?
Mandate: What professional or institutional purpose is being asserted?
Review outcome: Has the evidence been evaluated sufficiently to justify approval?
Government bodies introduce another variation.
A government authority is not necessarily expected to hold a commercial private-investigator licence.
Instead, verification may need to establish the public body's existence, the representative's identity, institutional authority, and mandate.
A verification system cannot simply treat every applicant as the same category of professional.
4. We Built Human Review Into the Process
Official registries and automated checks are useful.
But they have limits.
An automated check might confirm the existence of a registration number.
It might identify a professional licence record.
It might establish that a domain belongs to a particular organization.
None of these checks, individually, proves everything needed for final approval.
So our system combines structured evidence with human-governed decisions.
A simplified application lifecycle looks like this:
Application created
|
v
Applicant profile and evidence
|
v
Jurisdiction-specific requirements
|
v
Application submitted
|
v
Administrative review
|
+--> Approve
|
+--> Reject
|
+--> Request more information
|
v
Applicant correction
|
v
Re-review
Our current professional verification rules do not allow automatic final professional approval.
But rejecting incomplete applications immediately would create another problem.
A legitimate professional might upload an unreadable document, misunderstand a requirement, or submit evidence that needs clarification.
That shouldn't always mean starting from zero.
Which brings us to something we spent considerable time designing.
5. "We Need More Information" Should Be a Workflow, Not an Email
One of the most frustrating experiences in verification is receiving a vague response:
"Your documents are insufficient."
Which documents?
What was wrong?
What should be corrected?
And how does the reviewer know that the requested correction was actually made?
We developed a structured feedback workflow for this.
A reviewer can identify a specific issue involving a document, credential, professional mandate, declaration, or application field.
The system separates two kinds of communication:
Applicant-facing feedback, explaining what needs to be corrected.
Internal review notes, preserving information intended only for authorized reviewers.
A correction follows a defined lifecycle:
Open
|
v
Applicant submits a correction
|
v
Addressed
|
v
Reviewer checks the correction
|
v
Resolved
Notice the distinction between addressed and resolved.
A user submitting a replacement document doesn't automatically mean the reviewer has accepted it.
In our design, replacement evidence is also tied to the original evidence item.
This helps prevent a generic new upload from accidentally satisfying a request concerning a different document.
And when multiple administrators work on the same verification application, concurrency controls help prevent conflicting decisions.
This may sound like a lot of engineering for a verification form.
But verification is more than data collection.
It is a process that must be understandable, correctable, and accountable.
6. We Also Had to Govern the Rules Themselves
Here's a problem that doesn't become obvious until you build a system for multiple jurisdictions.
What happens when the legal source supporting a verification requirement changes?
Imagine a professional requirement references an official legislative document.
Months later, a reviewer discovers that the reference points to the wrong source.
Or a relevant rule changes.
Simply updating the URL isn't enough.
You also need to determine which verification requirements relied on the old source and whether their previous legal review is still reliable.
Our architecture includes governed legal-source records, source-readiness checks, versioned policies, and revalidation procedures.
One concrete example appeared during our review of Colorado requirements.
A source reference associated with a post-sunset private-investigator licensing route pointed to an unrelated legislative document.
The reference was corrected, and the dependent rule reviews were invalidated and explicitly revalidated.
The important lesson wasn't the particular state.
It was what the system did when the source changed.
A legal requirement should not remain trusted solely because it was reviewed successfully in the past.
We also maintain governed legal text and jurisdictional supplements, including a multilingual review process.
Historical acceptance evidence is preserved against the policy version applicable when it was recorded.
Publishing a newer policy must not silently rewrite what someone previously accepted.
This is where conventional application configuration starts becoming something closer to regulatory infrastructure.
7. Verification Was Only the First Layer
After solving much of the professional verification problem, we faced a second question.
Suppose an investigator is genuinely verified.
Should they automatically see every sensitive incident in the system?
No.
A fraud report might contain names, contact details, financial identifiers, screenshots, conversations, or allegations involving identifiable people.
Some information may require additional protections depending on its content and the applicable law.
The fact that a person is professionally eligible does not give them an unrestricted right to see that information.
So we separated three concepts.
Layer 1: Professional Verification
Who is the applicant, and what professional or institutional eligibility has been established?
Layer 2: Sensitive Access
Does this user or organization have the relevant permission to access protected incident information within the applicable scope?
Layer 3: Case-Use Authorization
Is the proposed use of this particular incident in this particular investigation permitted under the applicable requirements?
These are independent authorization boundaries.
Passing an earlier layer does not automatically satisfy the next one.
And an organization having access to a professional workspace doesn't automatically authorize every employee or collaborator to view every protected record.
This separation is fundamental to our security model.
8. Why Case-Use Became Necessary
Consider a hypothetical situation.
A victim reports an online scam.
The report contains personal data and supporting evidence.
Later, a verified investigator wants to attach that incident to an existing investigation.
At first glance, this may look like a simple database operation.
Incident
|
v
Investigation
But technically attaching the record could also make information available in another operational context.
The key question isn't only whether the investigator is verified.
It's whether the proposed use of the report is justified.
Why this investigation?
What is the purpose?
Does the investigator have the required authority?
Are additional declarations or supporting documents necessary?
Does the applicable legal framework permit this use of the relevant personal data?
We call this Case-Use Authorization.
Our system evaluates a specific Incident + Investigation pair, the actor's authority, and the applicable legal context.
Depending on the resolved requirements, the workflow may permit the action, require a declaration, require evidence-backed authorization, or deny it.
Not every case requires document submission.
And an authorization to use one incident in one investigation doesn't become blanket permission for unrelated cases.
Verification answers who you are. Case-Use asks whether this particular use is justified.
That distinction became one of the most important lessons in our development process.
9. The Law Doesn't Require Our Exact Architecture. It Requires Us to Respect the Boundaries.
This is an important distinction.
There is no single international law requiring every investigation platform to implement a product feature named "three-layer verification" or "Case-Use Authorization."
Those are our engineering decisions.
The underlying legal obligations vary.
🇪🇺 European Union
🇩🇪 Germany, 🇪🇸 Spain, 🇫🇷 France, 🇮🇹 Italy, and 🇵🇱 Poland operate within the EU GDPR framework.
GDPR Article 5 includes purpose limitation, data minimization, and accountability.
Article 6 requires an appropriate lawful basis for processing.
Article 9 can impose additional conditions for special-category personal data.
Article 10 imposes particular restrictions on personal data relating to criminal convictions and offences.
National law can further affect what processing is permitted.
🇬🇧 United Kingdom
The UK GDPR and Data Protection Act 2018 create their own framework.
Processing criminal-offence data can require additional authorization under domestic law or official authority, alongside an Article 6 lawful basis.
🇦🇺 Australia
The Australian Privacy Principles regulate collection, use, disclosure, and security of personal information.
APP 6 is particularly relevant when information collected for one purpose is proposed to be used or disclosed for another.
🇺🇸 United States
There isn't one universal state-independent rule for every investigation platform and category of personal data.
State privacy laws, sectoral requirements, professional licensing, and the nature of the information all matter.
California, for example, provides specific consumer rights concerning sensitive personal information under the CCPA as amended by the CPRA.
🇺🇦 Ukraine
Ukraine's Law on Personal Data Protection establishes legal grounds for processing personal information, including in Article 11.
The requirements must be evaluated for the relevant processing context rather than replaced by a generic claim of professional status.
Across these jurisdictions, the implementation details differ.
But the engineering concern is consistent:
A platform needs to know not only who is requesting information, but also whether the requested action is permitted.
Our Case-Use mechanism is one way we designed the system to enforce those distinctions.
It is not a substitute for a lawful basis, a required statutory authorization, or legal review.
10. A Successful Verification Doesn't Create Unlimited Trust
There is a wider security lesson here.
Developers often talk about authentication and authorization as though they are solved by login and roles.
But consider the difference between these statements:
"This user is authenticated."
"This user belongs to a verified organization."
"This user has permission to access sensitive incident information."
"This user is authorized to use this specific incident in this specific investigation."
They describe four different levels of assurance.
You cannot safely derive the last statement from the first.
The same principle applies outside OSINT.
A doctor may be licensed without being authorized to access every patient's records.
A lawyer may be professionally qualified without being entitled to every client's case files.
A financial analyst may work for a legitimate institution without having permission to inspect every customer account.
And a verified investigator may still need case-specific justification before using sensitive information.
That is why our system separates identity, eligibility, scope, and purpose.
11. What We Learned About Building Trust Into Software
This project changed how we think about verification.
We started with a question about applicants:
How do we know who should be allowed to use the platform?
But the more important question turned out to be:
How do we make sure that a valid account doesn't become an unrestricted gateway to someone else's personal data?
Several principles shaped our approach.
First, an official registry match is evidence, not a final decision.
Second, professional verification and access authorization must remain separate.
Third, applicants deserve structured, understandable feedback and a way to correct genuine mistakes.
Fourth, legal requirements need source provenance, versioning, review, and controlled updates.
Fifth, a verified professional's authority must be evaluated in the context of the specific activity.
And finally, an application's database permissions must reflect those decisions rather than trusting the frontend to enforce them.
We're still learning as we build Axon OSINT, and maintaining these controls requires ongoing legal and technical review.
But one principle is unlikely to change:
Trust should never be a permanent, universal permission granted by a single successful check.
Final Thought
Building verification across nine countries forced us to think beyond documents, badges, and approval buttons.
It pushed us toward a system where professional eligibility, sensitive access, and case-specific authorization are different decisions with different evidence.
Because in an investigation platform, the most dangerous mistake isn't necessarily failing to verify someone.
It may be verifying them correctly — and then assuming that verification gives them permission to do everything.
Knowing who someone is does not tell you what they're entitled to do.
That's the distinction we wanted our software to respect.
Let's Discuss
Have you worked on a product where identity verification wasn't enough to authorize access?
How did your team handle professional credentials, jurisdiction-specific rules, sensitive information, or case-specific permissions?
I'd be interested to hear how other developers approach these problems.
We're building Axon OSINT, a platform for digital investigations and professional OSINT research.
This article is part of our **Building Axon OSINT* engineering series. It describes architectural principles rather than disclosing private applicant information, internal decision thresholds, or sensitive authorization implementation details.*
*The regulatory discussion is intended as engineering context, not legal advice. Applicable requirements depend on the jurisdiction, data, parties, and processing purpose.
Legal sources:
🇪🇺 EU GDPR — Articles 5, 6, 9 and 10
🇬🇧 UK ICO — Criminal offence data
🇦🇺 Australia OAIC — APP 6
🇺🇸 California — Privacy rights under CCPA
🇺🇦 Ukraine — Law on Personal Data Protection
Top comments (0)