How to Verify Anything You Read About ADA Assessments
Every ADA requirement is published openly, versioned and free to read, so you never have to take a vendor’s word for what a programme demands. Where to look, what to check in ten minutes, the version trap that catches careful people, and the licence position almost nobody mentions.
App Defense Alliance
Everything the App Defense Alliance requires of your application is published openly, versioned, and free to read. So you never have to take anybody's word for what a programme demands — including ours.
In short. The requirement sets live in a public GitHub repository under a Creative Commons licence. Ten minutes there will tell you whether a vendor describing these programmes actually knows them. This article shows you where to look, what to check, and the three places the repository will not help you.
Why this matters more than it sounds
Security certification is a field with a lot of confident talk in it. Somebody tells you an assessment is legally mandatory, or that a particular badge means your application is secure, or that their firm is authorised to issue a report. Most of the time nobody is lying. They are repeating something they heard, and it has drifted a little further from the truth at each retelling.
ADA programmes are unusually resistant to that, because the requirements are not a private document you receive after signing. They are in a public repository with a commit history. You can read the exact bar, see when it last changed, and check any claim against it yourself.
There is a catch, and it is the reason this article exists. These are versioned requirement sets. An article written against one version and left undated ages badly and silently, because nothing on the page tells you it has gone stale. The same applies to a proposal, a scope document, or a vendor's website.
Where the source actually is
| What | Where |
|---|---|
| The repository | github.com/appdefensealliance/ASA-WG |
| Version history | the releases page — check this on the day you rely on anything |
| Profile folders | /MASA, /CASA, /DASA, /Cloud App and Config Profile, and an /AI Profile still in development |
| Programme-wide documents | The scheme overview, the evaluation methodology and the laboratory authorisation document sit at the repository root |
| Licence | Creative Commons Attribution-ShareAlike 4.0 International. This matters more than you would expect; see below. |
Watch the branch. The repository has more than one branch, and the default you land on may not be the one a specification was published from. If a detail matters, note which branch and which commit you read it on. Two people quoting the same repository can genuinely disagree if one is reading main and the other develop.
What you can check in ten minutes
These are all directly verifiable in the repository. If a vendor's description of a programme contradicts one of them, that is worth a question.
| Claim | What the source shows |
|---|---|
| MASA is an Android programme | It covers Android, Apple iOS and Meta Quest. The platform is the leading digit of every requirement identifier. |
| There are two assurance levels | The README describes three: AL0 self assessment, AL1 developer tested and lab reviewed, AL2 lab tested. Individual profile specifications may present fewer. |
| Every profile publishes three documents | The profile folders carry a Specification and a Test Guide. An Audit Summary is not present in every profile folder, so do not assume one exists for yours. |
| The Cloud profile is part of CASA | It is a distinct profile with its own folder and specification, built on CIS benchmarks, covering AWS, Google Cloud and Microsoft Azure across six domains. |
| DASA is for desktop applications only | The specification covers native desktop software on Windows, macOS and Linux, including Electron and CEF applications, software talking to back-end APIs, and installers and updaters. |
| The profiles have always had these names | The Mobile App Profile was renamed MASA and the Web App Profile renamed CASA at release v2.0.0. Legacy folder names still appear in the tree. |
How to read a Test Guide entry
This is the single most useful skill, and almost nobody does it. The Specification is a two-column list: an identifier and a one-line description. It tells you a requirement exists. The Test Guide tells you what will actually be accepted, and that is what determines whether you pass. The self-assessment and evidence guide works through that in detail, with worked examples.
Each requirement entry carries a fixed set of fields:
| Field | What it gives you |
|---|---|
| Description | The requirement itself, in one sentence. |
| Rationale | Why it is there. Useful when you want to argue that it does not apply to you. |
| Audit | What the assessor is checking for. |
| Evidence | What you must actually submit. This is the field to read first, and it is frequently written per assurance level, so what AL1 asks of you differs from AL2. |
| Test Procedure | How the check is performed. You can run this yourself before anyone bills you. |
| Verification | What a satisfactory result looks like. |
| Additional Context | Supplementary guidance, present where the requirement needs it rather than on every entry. |
In short. Read the Evidence field before you plan anything. It tells you what you have to produce, and at AL1 producing it is your job, not the laboratory's. A team that reads only the Specification consistently underestimates the work, because the Specification never mentions evidence at all.
The version trap
Here is the mistake that catches careful people. The repository has a release tag. The individual documents also carry their own version stamp. They are not always the same number.
A release can introduce a new profile without revising the existing ones. When that happens the repository tag moves forward while the untouched specifications keep the version they were last revised at. Quoting the repository tag as though it were the version of the document you read is a small error that makes a scope document wrong.
So when you record a version, record the one printed inside the document you actually relied on, together with its date, and note the repository release separately if you need it. Your scope agreement should name a document version, not a repository tag.
Four things the repository cannot tell you
The ADA repository is authoritative for the requirements. It is not authoritative for everything people attach to these programmes, and this is where most confident misinformation lives. For each of these, the repository is the wrong place to look.
1 — What appears on your app store listing
Whether an independent security review note is shown, and its exact wording, is decided by the store, not by ADA. Check the platform's own current developer documentation, and get what your laboratory will publish in writing before you start.
2 — Whether a platform requires an assessment of you
Nobody is required by law to do any of this, anywhere. You may be required by a platform's terms or by a customer contract, which in practice binds just as hard. That obligation lives in the platform's documentation or in your contract, not in the requirement set.
3 — Renewal periods
Validations lapse and have to be renewed, but the period is a programme and platform matter rather than a line in the requirement set. Confirm the figure for your specific profile with your laboratory, and put the renewal in the calendar two months early.
4 — Which assurance levels your profile offers
The README describes three levels programme-wide, but an individual profile's specification may present only some of them. Read your own profile's specification rather than the README, because this determines whether you need a laboratory at all.
The licence, and why it is not a footnote
The repository is licensed under Creative Commons Attribution-ShareAlike 4.0 International. Almost nobody who writes about these programmes mentions it, and for a commercial website there are two real consequences.
Attribution is not optional
Where you draw on the material, the licence asks you to identify the creator, name the licence, link to the source, and indicate whether you changed anything. That is four things, and most pages that quote requirement identifiers do none of them. If you are publishing a requirements summary for your customers, it costs a paragraph to do properly.
ShareAlike can reach further than you expect
ShareAlike applies to adaptations. If what you publish is an adaptation of the licensed material, your version has to go out under the same or a compatible licence. Explaining requirements in your own words, with short attributed quotations, is a different act from reformatting and republishing the requirement set itself.
That distinction is worth caring about before you build a customer-facing checklist tool or a tidied-up copy of a requirement table. The cautious position, and the one this site takes, is to explain and teach rather than republish. If you want to publish a reformatted copy of the requirements themselves, take advice first, because ShareAlike can reach the work you place it in.
Worth asking. If a vendor hands you a polished spreadsheet of the requirement set as a sales asset, ask what licence it is under. Either they wrote it themselves, in which case it is their interpretation rather than the standard, or it is an adaptation of CC BY-SA material and the licence terms travel with it. Neither is a problem. Not knowing which is.
Why every page about a versioned standard needs a date
If an article tells you a programme has a particular number of requirements, or a particular renewal period, and does not say when it was written or which version it describes, you cannot use it. Not because it is wrong, but because you have no way to know whether it is still right.
Apply that to what you read here too. This article carries a date. When a detail would be expensive to get wrong, open the repository and check it yourself on the day, rather than trusting any secondary description, ours included.
What to ask a firm that says it is “working towards authorisation”
This phrase is going to become common, because a number of firms are pursuing authorisation and the process takes time. It is an honest thing to say. It is also vague enough to hide behind, so here is how to read it.
- Authorised, or working towards it? These are completely different. Only an authorised laboratory can perform the validation that the programme recognises. Ask directly, and verify against the published list rather than accepting a statement in a proposal.
- Authorised for which assessment type? Authorisation is per assessment type. A laboratory authorised for MASA is not automatically authorised for CASA or DASA.
- What are you buying, exactly? Readiness testing and formal validation are different products. Both are legitimate. Confusing them is expensive, because only one of them produces a report the programme recognises.
- Does this work disqualify them later? A firm that does your readiness work generally cannot then be the laboratory that validates you, because it would be assessing its own advice. A firm that does not volunteer this has not thought about it, or would rather you found out later.
Apply all four to us as readily as to anyone else. Adayptus is not an ADA-authorised laboratory today. We are building our laboratory management system to ISO/IEC 17025:2017 and working towards authorisation, and we will keep saying so plainly on this page until that changes. What we sell today is readiness work, and doing it for you makes us ineligible to validate you afterwards.
A ten-minute verification routine
Step 1 — Open the releases page
Note the current release and its date. Do this on the day you are relying on it, not once a quarter.
Step 2 — Open your own profile's folder
Confirm which documents actually exist in it rather than assuming a standard set, and note the version stamped inside each one.
Step 3 — Read three Test Guide entries in full
Pick three requirements you believe you already meet and read every field, especially Evidence. This is the fastest way to calibrate how much work the assessment really is.
Step 4 — Check the assurance levels in your profile
Not the README. Your profile's own specification, because it decides whether you need a laboratory.
Step 5 — Write down what you checked and when
Document version, date read, branch. It takes one line and it is what makes your scope agreement defensible six months later.
Frequently Asked Questions
Click any question to expand the answer.
QDo I really need to read the source myself?
If you are buying an assessment, yes, at least the parts that affect scope and cost. It is free, it takes an afternoon, and it changes the conversation with a vendor completely. You stop being told what the programme requires and start checking it.
QIs any of this legally required?
No, nowhere in the world. If somebody tells you an ADA assessment is legally mandatory, they are either confused or selling something. You can still be required by a platform's terms or a customer contract, which in practice binds just as hard, but that is a commercial obligation rather than a legal one.
QWhy does the document version differ from the repository release?
Because a release can add a new profile without revising the existing ones. The repository tag moves; an untouched specification keeps the version it was last revised at. Always record the version printed inside the document you actually read, with its date.
QWhich document should I read first?
The Test Guide for your profile, not the Specification. The Specification tells you a requirement exists; the Test Guide tells you what evidence will be accepted, which is what actually determines whether you pass.
QCan we just republish the checklist for our own team?
Internal use is a much simpler question than publication. The licence terms bite when you distribute. If you are publishing a reformatted version of the requirement set to customers or on your website, look at the ShareAlike condition properly, and take advice if the answer is not obvious.
QHow do we check whether a laboratory is really authorised?
Against the published list, not against a claim in a proposal or a logo on a website. Check the assessment type too, because authorisation is granted per assessment type rather than across the board.
QDoes a pass mean our application is secure?
No, and be careful of anyone who says otherwise. A pass means your application met the requirements that were tested, in the version tested, on the date tested. It is a meaningful, independently checked baseline, which is a different and more honest claim than security.
QIs an AI profile coming?
There is an AI Profile folder in the repository, but the work is still developing and there is no settled requirement set to plan against yet. Treat anybody describing firm AI profile requirements today with caution, and watch the releases page.
QWhat if the source contradicts something we read here?
The source wins, and we would like to know. These are versioned documents and this article describes them as at its published date. Where a detail would be expensive to get wrong, check it at the repository on the day rather than relying on any secondary description.
Related reading
The requirement sets themselves are covered profile by profile: MASA for mobile apps, CASA for web applications and APIs, DASA for desktop applications, and the Cloud App and Config Profile for the infrastructure underneath.
On the engagement itself: what the laboratory actually does, how to choose an authorised laboratory, and how to prepare for your first assessment.
About Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India. We have been doing web, mobile and cloud security testing since 2018.
We are currently building our laboratory management system to ISO/IEC 17025:2017 and working towards authorisation as an App Defense Alliance Security Test Laboratory. We are not an ADA-authorised laboratory today. We will say so plainly on this page until that changes, because you should be able to trust what a security firm tells you about itself.
What we can do for you right now:
- Readiness testing against the published requirement set. We tell you what would fail before you pay for a formal validation. Depending on your profile that is mobile application, web application, API or cloud configuration testing.
- Fixing what we find. Guidance specific to your application, naming the component and the change, not a link to a general guideline. Where the cause sits in the source, secure code review is the faster route; where it sits in the design, threat modelling is.
- Evidence preparation. We help you assemble the documentation, architecture information and test accounts an authorised laboratory will ask for, so your validation does not stall on paperwork.
Please note. If we do your readiness work, we cannot later be the laboratory that performs your formal validation. Our impartiality rules stop us from validating an application we have already advised on. We would rather you knew that at the beginning than after you had paid us. If your priority is the formal validation, we will point you at an authorised laboratory and stay out of the way.
Attribution and source
Requirement identifiers, document structure, profile names and field names described in this article are drawn from material published by the App Defense Alliance in the ASA-WG repository at github.com/appdefensealliance/ASA-WG, licensed under Creative Commons Attribution-ShareAlike 4.0 International. No requirement text has been reproduced or adapted here; the explanations and advice are our own.
Programme requirements are versioned and they change. Before you rely on any specific detail in this article, check the current published requirements in the App Defense Alliance repository and its releases page, and the certification information on the App Defense Alliance website. Where this article describes how a process generally works, that shape is stable. Where it would matter to you whether a number or a version is exactly right, confirm it at the source.
Adayptus Consulting
Application Security Testing, Adayptus
Adayptus Consulting Private Limited is an application security testing firm based in Noida, India, working across web, mobile and cloud security testing since 2018. The firm is building its laboratory management system to ISO/IEC 17025:2017 and working towards authorisation as an App Defense Alliance Security Test Laboratory; it is not an ADA-authorised laboratory today.
On This Page
- Why this matters more than it sounds
- Where the source actually is
- What you can check in ten minutes
- How to read a Test Guide entry
- The version trap
- Four things the repository cannot tell you
- The licence, and why it is not a footnote
- Why every page about a versioned standard needs a date
- What to ask a firm that says it is “working towards authorisation”
- A ten-minute verification routine
- Frequently Asked Questions
- Related reading
- About Adayptus
- Attribution and source
