Cyber Coffee · English edition
A security roadmap from scratch: where to start when nothing is in place
How to turn a list of risks into an action plan the team can execute, with results you can demonstrate.
· 6 min read
Taking responsibility for the security of a product without a structured program tends to produce a list that grows faster than your capacity to address it.
There are old credentials, outdated dependencies, permissions nobody reviews and questions about what data reaches the logs. Meanwhile, the product continues shipping features.
The question that stalls the work is: “How are we going to fix all of this?”
A more useful question is: which risk do we need to reduce first, who will take care of it and how will we verify that it improved?
A roadmap starts with those three answers.
Start with a short assessment and a concrete action
Before choosing tools, we need to understand what we are protecting.
That requires an initial inventory: applications in production, data processed, external integrations, technical owners and administrative access paths. It does not need to be perfect to be useful. It needs to support decisions.
Choose an important product flow, such as updating account details, and follow its path. Who can initiate the change? Where is authorization checked? Which service writes the data? What is recorded? Who can access that record?
This exercise connects security to the actual application and helps uncover problems that a list of tools will not reveal.
Assessment can happen alongside fixing obvious exposures. If a production credential is exposed, revoking it should not wait until the inventory is complete.
Record the problem, contain the exposure and use what you learn to broaden the assessment.
Prioritize by risk scenario
“We have a critical vulnerability” is initial information. To decide the order of work, we need to understand the context.
Is the component in production? Is it accessible from the internet? Is the vulnerable functionality used? Which data or operations could be affected? Is there any control that makes exploitation harder?
Consider a hypothetical example: the team finds a dependency with a high-severity alert in an isolated internal tool and an authorization flaw that allows access to another customer’s data in the public API.
The authorization flaw may deserve attention first, even if it does not have the highest score on the dashboard.
Practical prioritization considers the following:
- Impact: what could happen to customers, data and operations?
- Exposure: who can reach the vulnerable path?
- Exploitation conditions: what needs to happen for the issue to be exploited?
- Effort and dependencies: what is needed to fix or contain it?
Effort helps organize execution. It should not make a serious risk disappear from the list just because the fix is difficult.
When a permanent solution takes time, look for containment: restrict access, temporarily disable an operation or reduce permissions. That measure also needs an owner and a review deadline.
Turn each priority into a verifiable deliverable
“Improve access management” is an intention. It is not yet a deliverable.
A deliverable would be to review administrative access to production applications, remove unjustified permissions and record owners for exceptions.
The difference is the completion criterion.
Each priority must connect a problem to a deliverable and a way to verify the result. Consider four examples:
- 1. Credentials exposed in code. Problem: credentials accessible in code or repository history. Deliverable: revoke the identified credentials and correct their storage. Verification: confirm the old credentials no longer work and review the locations of exposure.
- 2. Accumulated administrative access. Problem: permissions remain active without need or justification. Deliverable: review access to priority applications and remove unnecessary permissions. Verification: check remaining access, its justification and its owners.
- 3. Possible cross-customer access. Problem: a user can read or modify another customer’s resources. Deliverable: fix authorization in the affected flow. Verification: test cross-customer access attempts and confirm they are blocked.
- 4. Unnecessary personal data in logs. Problem: logs store personal information without a need. Deliverable: reduce the fields recorded in the selected flow. Verification: inspect new records and handle historical data according to the applicable policy.
Installing a tool may be part of the deliverable. Completion needs to demonstrate that the control works.
Organize the first 90 days into stages
The period below is a proposed structure. The sequence should change when incidents, significant exposures or operational dependencies arise.
Days 1–30: understand the essentials and contain what is exposed.
Map priority applications and flows, identify owners and record the main risks. Fix urgent exposures found during the assessment. Also define who should be contacted when an incident is suspected.
By the end of this stage, the team should be able to explain its priorities and why they matter.
Days 31–60: make controls part of the routine.
Choose controls linked to the risks found. This may include access reviews, secret scanning during development, handling vulnerable dependencies or authorization tests.
Define who receives each alert and what happens afterward. An alert without clear follow-through becomes another forgotten queue.
Days 61–90: verify results and adjust the plan.
Test the implemented controls, review exceptions and compare the situation with the initial assessment. Use the results to choose the next set of deliverables.
If a control produces many unhelpful alerts, tune it. If a fix has not reached all planned applications, record the remaining scope. The roadmap needs to reflect operations.
Establish minimal governance from the start
Even a small program needs to record who makes decisions, who executes them and who can temporarily accept a risk.
An exception such as “this integration will keep using a long-lived credential for now” needs a justification, an owner, compensating controls where appropriate and a review date.
Without that, “for now” loses its deadline.
Initial documentation can be lean: a risk register, prioritization criteria, owners and a basic incident response procedure. It should accompany the work and allow someone else to understand the decisions.
As the program grows, that structure can become more detailed.
Measure reduced exposure
The number of tools installed and the volume of alerts found say little, on their own, about product security.
Look for measures that support decisions: how many priority applications have had their access reviewed? How many exposed credentials are still active? How long have significant risks remained untreated? Which critical flows already have authorization tests?
Also state the scope of the measurement.
“We reviewed all administrative access” means something different from “we reviewed access to three of the eight applications in production.” The second sentence makes the remaining work visible.
A good roadmap update shows what improved, what remains exposed and what decision needs to be made.
What to take away
Starting a security program requires choices the team can execute and verify.
Choose an important flow, understand its risks, contain the most urgent exposures and turn the next fixes into deliverables with an owner and a completion criterion.
The first roadmap can fit on one page. Its value lies in guiding next week’s work and showing, afterward, which risk was reduced.