How to Prepare for Your First ADA Assessment
A practical four-week plan before the laboratory starts. Most of what makes a first assessment expensive is avoidable, and almost all of it is avoidable before anyone bills you at lab rates.
App Defense Alliance
A practical four-week plan. Most of what makes an assessment expensive is avoidable, and almost all of it is avoidable before the lab starts.
In short. The single biggest cost driver in a first assessment is arriving unprepared. Four weeks of internal work before you engage a lab typically pays for itself several times over in reduced findings, fewer retests and shorter elapsed time.
What is this?
This is the work to do before a laboratory starts. None of it requires the lab's involvement and all of it reduces what the assessment costs you, in money and in elapsed time.
The logic is simple. A lab bills for its time and includes a fixed number of retests. Every problem you find yourself is a problem you fix at your own engineering cost rather than at lab rates, and a retest you do not consume.
Who is required to do this?
Nobody. It is entirely optional. It is also the difference between an assessment that goes smoothly and one that drags for three months, so treat it as optional in the way that testing your code before shipping is optional.
Week one: understand the bar
Step 1 — Confirm which assessment you need
And whether you need more than one. Getting this wrong wastes the whole exercise.
Step 2 — Download the requirement set and the Test Guide
Everything is published free at github.com/appdefensealliance/ASA-WG. Get your profile's Test Guide, not just the Specification: the Specification lists the requirements, the Test Guide tells you what evidence is accepted. Note the release version you are working against.
Step 3 — Confirm your assurance level
AL0, AL1 or AL2. This changes everything downstream, because it determines whether you are producing evidence for a reviewer or preparing for hands-on laboratory testing. Do not assume the lightest.
Step 4 — Identify who owns each requirement area
Authentication may be one team, cloud configuration another, the mobile client a third. Assign owners now.
On step one. Which profile applies depends on what you build: CASA for web applications and APIs, DASA for desktop and server software, and the Cloud App and Config Profile for the infrastructure underneath. A product with a client and a back end usually needs more than one, which is exactly the mistake step one exists to catch.
Week two: find your own problems
Step 1 — Self-assess honestly against every requirement
Mark each Pass, Fail or Unsure. Resist optimism. Every Unsure is a likely Inconclusive on your real report, and Inconclusive verdicts are wasted money.
Step 2 — Run the automated tooling
A scanner for web and APIs, your cloud provider's own configuration assessment tool, dependency scanning everywhere. This is cheap and finds a real share of the issues.
Step 3 — Search for secrets
Source control history, container images, configuration files, the mobile app package. Rotate anything you find, because a committed secret must be assumed compromised.
Step 4 — Audit access control by hand
For web and APIs this is the highest-value manual work available. Check that every endpoint verifies the caller may touch the specific object requested, not merely that they are logged in. Tools miss this and it is the most common serious finding.
Step 5 — Check the obvious mobile and desktop traps
Debug flags, disabled certificate validation, verbose logging, plain-text token storage, unsigned updates, services running with more privilege than they need.
Week three: fix and prepare evidence
Step 1 — Fix in order of what a lab would call serious
Anything publicly exposed, anything involving credentials, anything allowing one user to reach another's data. Cosmetic findings can wait.
Step 2 — Update your dependencies
Especially in mobile and desktop products, where nothing forces them to update and they rot for years.
Step 3 — Write down your architecture
The lab will ask. A diagram, a data flow, a list of endpoints or components, and where data is stored. Preparing this in advance removes days from the engagement.
Step 4 — Document your intentional exceptions
If a requirement genuinely does not apply to you, write down why now, while you remember. This becomes the scoping conversation.
Step 5 — Decide what you will self-attest
Some requirements you may ask the lab to accept on your statement rather than validate. Be aware this is disclosed in the report, so choose deliberately rather than by accident.
Week four: get logistics out of the way
This is the unglamorous week that prevents most delays.
| What to prepare | Why it matters |
|---|---|
| Test accounts, at least two at different privilege levels | The commonest cause of delay in the entire process. Without two accounts, access control cannot be tested at all. |
| A stable environment that resembles production | If you offer staging and it differs from production, the results mean less and the report has to say so. |
| Written authorisation to test | Including from any third party hosting part of your stack. This routinely blocks start dates. |
| Licence keys and installable builds | For desktop products, for every platform in scope. |
| Read-only configuration access | For cloud assessments. Grant it formally rather than sharing somebody's credentials. |
| A named technical contact who can answer within a day | Slow answers extend engagements more than anything the lab does. |
| A decision on who signs the scope agreement | Somebody with authority to commit, available in the engagement window. |
| Time in your own roadmap for fixing | Book engineering capacity for the weeks after the report arrives. Teams forget this and then cannot use their retests before the deadline. |
What not to do
- Do not book the assessment against a hard external deadline with no slack. You need room to fail, fix and retest. Two weeks before a partner launch is not a plan.
- Do not hide known problems. The lab will find them, and it will cost a retest you could have avoided. Fix them or disclose them.
- Do not change the application during testing. It invalidates work in progress and confuses which build was assessed. Freeze the build.
- Do not treat exclusions as a way to hide failures. Anything excluded is disclosed in the report, so the reader sees the gap.
- Do not have the firm doing your readiness work also do your validation. It is not permitted, and finding out late wastes the readiness engagement.
How much this saves
We cannot give you a number that would be honest across every product. What we can say directionally, from how these engagements run: a prepared team typically consumes fewer of its included retests, spends less elapsed time waiting, and receives fewer Inconclusive verdicts, which are the pure waste in the process because you paid for a requirement to be assessed and got no answer.
The corresponding cost is a few weeks of internal effort, most of it work you would have wanted to do anyway.
Frequently Asked Questions
Click any question to expand the answer.
QIs preparation required?
No. It is optional and it is the highest-return optional thing available to you in this process.
QHow does preparing actually help us?
Fewer findings, fewer retests consumed, shorter elapsed time, and fewer Inconclusive verdicts. It also means the findings you do get are the interesting ones rather than a list of things you already knew.
QDo we need to do this every year at renewal?
Much less. The first assessment carries the accumulated backlog of everything never reviewed. Renewals only need to cover what changed in the year, provided you kept up. If you rewrote a large part of the product, treat it as a first assessment again.
QCan we hire someone to do the preparation?
Yes, and many teams do, particularly for a first assessment. Be aware that a firm doing your readiness work will usually be barred from performing your formal validation, so plan for two firms.
QShould we do a full readiness assessment or just self-assess?
Self-assess first, always, because it is free and it tells you how big the problem is. If the self-assessment shows a lot of Unsure answers or a lot of failures, a readiness assessment is worth the money. If it shows a handful of known issues, fix them and go straight to the lab.
QWhat if we cannot fix everything before the assessment?
That is completely normal and not a reason to delay indefinitely. Fix the serious things, be honest in scoping about what you know is weak, and use the retests. A first attempt with failures is a respectable outcome.
QHow far ahead should we book the lab?
Ask about lead times early, because good labs are booked out. Book the slot while you do your preparation, rather than finishing preparation and then waiting six weeks for availability.
QWho should own this internally?
Somebody with authority to get engineering time allocated. Preparation that lands on a security team with no ability to prioritise developer work tends not to happen.
QWho actually sees the result?
That depends on the programme. Some results appear as a badge or a note on an app store listing that your users can see. Others are shared with the platform that asked you to get assessed, and are not public. Ask the lab what will be published before you start, and get it in writing. A good lab will not publish anything about your app without your written consent.
QWhat if we disagree with a finding?
You can dispute it. An authorised lab has to have a documented dispute process, and the person who decides your dispute must not be the person who made the finding. If the verdict changes, the lab has to update the report with ADA. Ask to see the dispute process before you engage a lab.
QDoes a pass mean our app is secure?
No, and be careful of anyone who tells you it does. A pass means your app met the requirements that were tested, in the version that was tested, on the date it was tested. It is not a guarantee. It is a meaningful, independently checked baseline, which is a different and more honest thing.
QCan we use our own internal security team instead?
Not for the formal validation. The whole value of these programmes is that the tester is independent of the developer. Your internal team is exactly the right people to do the preparation work and the fixing, but the validation itself has to come from an authorised lab.
QCan the lab help us fix the problems it found?
It can tell you what to change, and it should: specific remediation guidance for each failed requirement is a programme requirement, not a favour. What it must not do is implement the fix for you, because then it would be validating its own work. Advice yes, hands on your codebase no.
Related reading
Once you have worked through the four weeks, the next decision is who does the validation. How to choose an ADA authorised laboratory covers the questions to ask, the answers that should end the conversation, and how to compare quotes that differ threefold on scope alone.
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. We test your app against the relevant requirement set and tell you what would fail, before you pay for a formal validation. Finding out early is much cheaper than failing late. That is web application, API or cloud configuration work depending on the profile.
- Fixing what we find. We give you guidance specific to your application, pointing at the actual component and the actual change needed, not a link to a general guideline. Where the cause sits in the code, secure code review is usually the faster route.
- Evidence preparation. We help you assemble the documentation, architecture information and test accounts an authorised lab will ask for, so your validation does not stall on paperwork.
Please note. One thing we will tell you up front: if we do your readiness work, we cannot later be the lab that performs your formal ADA 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 lab and stay out of the way.
Attribution and source
Requirement identifiers, domain names and profile names 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. The explanations and remediation 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. 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.
