How to Run a Security Assessment Across 90 Applications in 90 Days

When an application portfolio is too large to pen-test, an inquiry-based maturity assessment gets you a defensible, board-ready picture in weeks instead of years. Instead of asking every team for evidence, you score each application against a short set of risk-ranked questions, map the answers to a maturity scale, and turn the result into a heat map the business can act on. I ran this myself on an engagement I was handed personally: 90 applications for a multinational with more than 60,000 employees and over 50 million customers, with two analysts and a 90-day window.

Why pen-testing every application is the wrong tool at this scale

Penetration testing and scanning do not scale to a 90-application portfolio on a fixed timeline. The applications sat on different infrastructure, some on-prem and some spread across cloud providers and data centers in different regions, and many arrived through acquisitions, so they carried different postures, owners, and security baselines. Testing each one properly would take far longer than the 90 days available, and the results would arrive too late to inform a single executive decision.

The deeper reason is that the CISO did not need proof that a specific injection flaw existed in application 47. He needed to know, across the whole portfolio, which applications were weak in which security capabilities, so he could direct budget and attention. That is a question about coverage and maturity, not a question a scan answers. A vulnerability scan tells you what is broken on one system today. It does not tell you whether a program exists to keep it from breaking again.

What an inquiry-based security assessment is

An inquiry-based security assessment scores each system through structured interviews against a fixed question set, rather than collecting and testing evidence artifact by artifact. You decide in advance which security capabilities matter most, write a small number of questions that reveal maturity in each, and hold a working session with the team that owns each application. The output is a consistent maturity score per application per capability, not a pile of screenshots.

The method trades depth of proof for breadth of coverage, and that is the right trade when the goal is to direct a program rather than certify a single system. It resembles a maturity review more than an audit. It sits alongside, not instead of, deeper technical testing: you use the assessment to find the red applications, then spend your scarce pen-testing budget on those.

How to design the question set

The question set is where the assessment succeeds or fails, so build it from the organization's actual risks, not a generic checklist. On this engagement I wrote roughly 35 questions covering the 8 to 9 security capabilities the CISO had ranked as highest risk for the business. He was a capability-first leader who had already funded shared services for several of them, so the questions doubled as an adoption check on capabilities the company had paid to build.

Each question mapped to a real capability the organization cared about:

I mapped every question to ISO 27001 and NIST references so that any team that pushed back on being asked could see the question was grounded in a recognized standard, not an auditor's opinion. The framework reference is there to add weight, not to run the assessment. For the underlying discipline of building these capabilities as a system rather than a checklist, the GRC engineering guide covers the operating model.

How to build a maturity scale that produces real data

Give every question its own five-level scale, worded for that specific capability, so a score means the same thing to everyone who reads it. A generic rate yourself 1 to 5 produces numbers nobody trusts. Anchoring each level in observable behavior produces a score you can defend to an executive.

For static application security testing, the five levels read roughly like this:

1. None. The application has never undergone SAST.
2. Ad hoc. It has been tested, but irregularly, or not within the last year.
3. Annual. Testing happens on a defined annual cadence and findings are tracked.
4. Managed. Testing happens more than annually, findings are remediated, and reporting is in place.
5. Optimizing. The team continuously improves the scanning and remediation process itself, with strong reporting.

The same maturity logic underpins a security architecture review, where the point is to locate the gaps that matter, not to hand out passing grades.

Why interviews beat a questionnaire link

Send a form and you get low-quality data; hold an interview and you get context, anecdotes, and the truth. A raw questionnaire returns numbers with no way to tell an honest 3 from an optimistic one, and it strips out the specific challenges a team is facing. I ran working sessions with all of the roughly 30 teams instead, some owning a single application and some owning several.

Interviews did three things a form cannot. They let the assessor probe when an answer sounded too clean, so the score reflected reality. They surfaced the specific problems a team was stuck on, which became findings the assessment could relay upward. And they built the relationships that later turned a red score into a request for help rather than a defensive argument. The ownership map mattered here: because every application already had a named owner, scheduling and accountability were straightforward.

How the dashboard turned scores into action

The assessment produced roughly 1,800 data points, and the dashboard is what made them move the organization. Ninety applications scored across about 30 columns gives 1,800 cells, each color-coded red, yellow, or green, with the application's owner and the responsible VP and senior VP named at the top. The CISO briefed the results monthly, and the deck circulated widely.

What to do if you are facing a large-portfolio assessment

1. Rank the capabilities before you write a single question. Decide with the accountable security leader which 8 to 10 security capabilities carry the most risk. The assessment scope follows the risk, not the other way around.
2. Write one five-level scale per question, worded for that capability. Make level 5 genuinely hard. A believable spread of scores is more useful than a green wall.
3. Map each question to a recognized standard. ISO 27001 and NIST references defuse the why are you asking this objection before it starts.
4. Interview, do not survey. Book working sessions with each owning team. Probe the clean answers, capture the anecdotes, and record the specific blockers as findings.
5. Name the owners on the dashboard. Color-code every application by capability and put the accountable VP at the top of the view. Visibility is the mechanism that converts a score into remediation.
6. Point the deep testing at the red. Use the assessment to triage, then spend pen-testing and vulnerability assessment budget on the applications that scored worst.

The takeaway

You can assess a security program across 90 applications in 90 days without testing a single one, if you accept that the goal is direction, not proof. The value was never in one more finding on one more system. It was in giving the executives a single, honest, color-coded view of where 90 applications stood across the capabilities that mattered, and in making that view visible enough that the red rows fixed themselves. Coverage first, depth where it counts. That is how a two-person team moved a 60,000-person company.

Frequently Asked Questions

How do you do a security assessment of 90 applications in 90 days with limited resources?

Assess maturity through structured interviews instead of testing every application. Rank the 8 to 10 security capabilities that carry the most risk, write about 35 questions with a five-level maturity scale for each, and hold a working session with the team that owns each application. Two analysts can cover roughly 30 teams this way in the window, producing a scored maturity picture per application. Point your scarce penetration-testing budget only at the applications that score red.

What is an inquiry-based security assessment?

It is a method that scores each system through structured interviews against a fixed, risk-ranked question set, instead of collecting and testing evidence system by system. Each answer maps to a maturity scale, producing a consistent score per system that shows where a program is strong or weak across many applications at once.

How is a security assessment different from a penetration test?

A penetration test proves whether a specific vulnerability can be exploited on one system. A security assessment measures the maturity and coverage of a security program across many systems. Use an assessment to find the weak applications, then direct penetration testing budget at those.

How many questions should a maturity assessment use?

Enough to cover the highest-risk security capabilities without exhausting the interviewees, often around 30 to 40. On a 90-application engagement, roughly 35 questions covering 8 to 9 capabilities produced about 1,800 scored data points while keeping each interview to a manageable length.

Why use interviews instead of a self-assessment form?

Forms return numbers with no context and no way to distinguish an honest score from an optimistic one. Interviews let the assessor probe unclear answers, capture the specific problems each team faces, and build the relationships that turn a poor score into a request for help rather than a defensive dispute.

How do you get a large organization to act on the results?

Make the results visible and attributable. A dashboard that color-codes every application by capability, with the accountable VP and senior VP named, briefed regularly to executives, creates the pressure that moves teams. Owners of red items reach out for help because the state of their application is visible to leadership.