Use case
Securing a system starts with knowing where the real risks are.
Security can absorb an unlimited budget without ever feeling like progress. The point is not to cover everything: it is to know what is genuinely exposed, what that would cost, and which fixes reduce the risk first.
You may recognise some of this
None of this is unusual. It describes most systems that grew faster than their reviews.
- An internet-facing application has changed a lot with no security review.
- Part of the infrastructure predates current practice and nobody has revisited it.
- Technical dependencies no longer receive updates.
- Access rights widened as needs came up and were never narrowed back.
- Network segmentation is weak: from one workstation you can reach a lot.
- There is no real visibility: neither usable logs nor alerting.
- A client or an upcoming audit will ask for evidence you cannot produce today.
What happens if nothing is done
Without drama: most incidents are not spectacular, and that is precisely what makes them expensive.
- Exposure grows with nobody tracking it
- Every new service, test environment or partner integration adds surface. Without an inventory, that growth is visible nowhere.
- Fixes turn into projects
- The longer a dependency stays behind, the riskier the update becomes. At some point, fixing a known vulnerability takes a project instead of an intervention.
- Incident response happens blind
- Without usable logs, understanding what happened, how far someone got and which data is involved becomes a long investigation — while the business waits.
- The pressure arrives from outside
- A client security questionnaire, an audit or an insurance requirement then imposes a timeline you did not choose, on a scope you do not control yet.
Audit, hardening, penetration test or ongoing support?
These answer different questions and do not replace each other. Doing them in the wrong order wastes time and money.
| Audit, hardening, penetration test or ongoing support? | What it gives you | What it does not replace |
|---|---|---|
| Review and audit | An overview: what exists, what is exposed, where the gaps are against expected practice. Usually the right starting point. | Proof that a weakness is exploitable. An audit identifies gaps; it does not demonstrate what an attacker would obtain. |
| Fixing and hardening | An actual reduction in risk: updates, narrower rights, segmentation, configuration, removing what no longer serves. | An architecture review. Some problems come from a design, and no amount of hardening fixes them for good. |
| Penetration test | What an attacker would actually obtain on a defined scope, through which path, and with what business impact. | The remediation work. A report with no fixing pass changes nothing about your security posture. |
| Retest | Confirmation that the fixes hold, with an updated status per finding. Useful to produce for a client or an auditor. | A full new test. A retest covers the items addressed, not what changed since. |
| Continuous improvement | Holding the level over time: dependency tracking, reviews when things change, monitoring and access management. | A one-off action on an identified problem. Continuity does not catch up accumulated backlog, it stops more from building up. |
Starting with a penetration test on a system that has never been reviewed usually produces a long report whose first pages were predictable. A prior review costs less and makes the test more useful.
Where the risk sits, layer by layer
Security does not happen in one place. An attack path crosses several layers, and one control holding on any of them is enough to stop it.
- Internet
- Exposed application
- Application account
- Internal network
- Data
- IdentitiesExposedControl : Strong authentication, rights narrowed to what is needed, periodic account review.
- ApplicationExposedControl : Access control enforced server-side, input handling, dependencies kept current.
- APIsExposedControl : Per-resource authorisation, rate limiting, retirement of old versions.
- DataInternalControl : Encryption, separation by purpose, backups whose restore is actually tested.
- InfrastructureExposedControl : Surface cut to what is needed, patches applied, configuration described as code.
- NetworkInternalControl : Segmentation between environments and between purposes, framed remote access.
- OperationsInternalControl : Logs kept and usable, alerts wired to someone who responds.
- People and proceduresExposedControl : Joiner and leaver handling, a known incident procedure, awareness based on real cases.
This breakdown is there to locate risk, not to promise full coverage. The scope actually addressed gets defined at scoping, layer by layer.
Where to start
A useful security effort is a prioritised one. The order of the steps matters as much as the steps.
- 01
Identify the critical assets
Which applications and which data the business cannot run without, and which would do the most damage if compromised or unavailable.
- 02
Measure real exposure
What is reachable from the internet, from the internal network, from an ordinary user account. This step almost always surfaces forgotten assets.
- 03
Assess the consequences
Business interruption, data loss or leak, notification obligations, impact on your own clients. This is what allows ranking by something other than a technical score.
- 04
Look at the controls already in place
Many organisations have more protection than they think, misconfigured or unmonitored. Making it work costs less than buying more.
- 05
Look for vulnerabilities where it counts
Once the scope is prioritised, the search for weaknesses focuses on what is critical and exposed, not on everything at once.
- 06
Build an improvement plan
What gets fixed now, what gets scheduled, and what is accepted as a documented risk. A plan that gives nothing up is not a plan.
Accepting a risk explicitly, knowingly, is a valid decision. The problem is not the accepted risk: it is the ignored one.
Security is not a single test
A test is a photograph taken on a date. What holds a security level is what happens between two tests.
The system changes constantly
A release, a new integration or a change of hosting alters the exposed surface. A six-month-old report describes a system that no longer quite exists.
Dependencies age on their own
Code you have not touched becomes vulnerable when a flaw is published in a library it uses. Dependency tracking is an ongoing activity, not an audit.
Access accumulates
Rights get added project after project and are rarely removed. A periodic review of accounts and permissions fixes more real risk than a lot of tooling.
Fixing is not the same as designing
Some vulnerabilities are one-off mistakes; others are the consequence of an architectural choice. The first get fixed, the second get decided.
What this can look like
Depending on the starting point and the level of maturity, a security effort takes very different shapes.
- An inventory of the genuinely exposed surface, often wider than expected
- A rights review and a reduction of access accumulated across projects
- A dependency catch-up, with continuous tracking afterwards
- Network segmentation that limits what is reachable from a workstation
- Usable logs and alerts wired to someone who responds
- A prioritised remediation plan, with what is fixed, scheduled or accepted
- A penetration test once the ground is prepared, then a retest of the fixes
These describe possible shapes of a solution, not delivered projects presented as references.
This path may draw on
Depending on whether the subject is the code, the infrastructure, or demonstrating the actual level.
Frequently asked questions
Should we start with a penetration test?
Not always. On a system that has never been reviewed, a test usually produces a long report whose first pages were predictable: outdated dependencies, over-broad rights, default configuration. A prior review costs less, lets you fix the obvious, and makes the test genuinely informative. That said, if a client requires evidence of an independent test, the order is set by the context.
What is the difference between fixing a vulnerability and improving the architecture?
Fixing a vulnerability addresses a specific defect: a version to update, a missing check, an open configuration. Improving the architecture addresses what makes those defects possible or dangerous: separation, rights management, environment isolation. Both are needed, but they are not decided at the same level or on the same horizon.
Can a production environment be tested?
Yes, with a framework. Excluded tests, testing windows and stop conditions are written before starting, and intensity is adjusted. Where a genuinely representative pre-production environment exists it is often preferable — but it has to be representative, otherwise the test says nothing about production.
How are recommendations prioritised?
By impact on your business, not by the technical score of the finding. A "medium" vulnerability on the system that carries your invoicing comes before a "high" one on a marginal internal tool. That is why identifying critical assets comes before looking for weaknesses.
How often should security be reviewed?
The most useful trigger is not the calendar but change: a new exposed application, a redesign, opening an API, a change of hosting. Many organisations also keep an annual rhythm on their external perimeter. Dependency and access tracking, on the other hand, is continuous.
Let us talk about your scope
Tell us what is exposed and what worries you. Taking stock is usually enough to surface the two or three real priorities.