Free assessment · answer in a few minutes
Technology and Architecture Risk Assessment
For technology leaders and architects who want to see where fragility sits in how systems depend on each other, change and recover.
Built by XONIK. Nothing you enter leaves this page.
In brief
This assessment shows where the risks sit in your technology and architecture, and what to examine first. Your answers about dependencies, change, recovery and visibility give an exposure band, then steps for the two areas that need attention, each assigned to a named role, in a PDF you can share. It is not a security audit.
Step 1 of 4: Dependencies
0 of 16 answered
- Dependencies (current step)
- Change (not yet reached)
- Recovery (not yet reached)
- Visibility (not yet reached)
Dependencies
Dependencies are the links between your systems, your suppliers and the platforms underneath them. A risk cannot be managed until you know what leans on what, because the weakest link is usually found by its failure.
Change
Change is how work reaches production, how it is undone and who may touch it. A change is the usual way a fault enters a running system, so the controls around it decide whether a small mistake stays small.
Recovery
Recovery is whether the business can restore service in a time it can bear, using people and steps that have been tried. A backup or a plan that nobody has exercised is a belief and not a capability.
Visibility
Visibility is how soon you learn that something is failing, and how well the reasons behind your systems are recorded and shown to the business. What cannot be seen cannot be fixed in time or argued for at budget time.
Answer the 4 questions left on this step to go on.
Your result
Where your points are
Your two weakest areas
Your strongest area
Want to talk through what this means for your organization?
Review your architecture with usOn this page
Where this assessment looks, and the checks it cannot run for you
The question this tool puts to your technology is where a small event would turn into a large one. A supplier changes its terms, an engineer leaves, a backup turns out not to restore. Each can be survived if the dependencies are known, the change can be undone, recovery has been tried and the failure is seen early. The questions take those conditions in turn and ask what is true, not what is intended.
It does not scan or test anything and will not find a vulnerability. The result does not say your systems are safe; it says how much of the control you describe is located, written down and proven.
Who should sit with it, and for how long
The head of engineering or the lead architect can answer much of it alone, but the recovery and visibility questions are often better known to the people who carry the pager. Add an infrastructure lead. Where two experienced people differ, the control is probably known to one and not written down for the other.
Give it a single sitting. If you stop to look things up it slows down, so note the question and move on; the notes become your list of checks.
| Area | The question it asks | Evidence that would settle it |
|---|---|---|
| Dependencies | What leans on what, inside and outside | A current map, a supplier list tied to functions, a calendar of support end dates |
| Change | How work reaches production and how it is undone | The record of the last change, with its way back |
| Recovery | Whether service returns in a time the business can bear | A timed restore, and a run book used by a second person |
| Visibility | How soon failure is seen, and by whom | The last incident review and the risk list that leaders read |
Turning a band into a decision about what to examine
The band names a state and the failure that usually follows it, so a low band is a reason to look and not a finding. A total built from even answers is a different situation from one that hides a single area near the bottom, which is why the result shows each area's share of the points and picks the two weakest. Each comes with steps that name the role who does them and what exists at the end, such as a timed restore record.
Treat your strongest area differently. Ask someone who did not write the answer to show you the evidence behind it.
Choose this, or commission a deeper review
A self-assessment fits when
- You need to decide where to look first, before paying for a review
- The leadership team wants a shared picture of technology risk
- A merger or a supplier switch is coming and you want to see what it would lean on
Commission something else when
- You need assurance for a regulator, a customer or an insurer, which calls for independent testing
- Your concern is a specific vulnerability or breach, which calls for a security assessment
- You need a design for a new platform, which calls for an architecture review
The trade is independence for speed: the people who know the systems best answer quickly, and have the most reason to see them kindly.
From result to evidence in the days that follow
- 01
Sort the answers
Mark each answer under your weakest area as known, believed or guessed.
- 02
Take one proof
Choose the cheapest check in the steps, such as a timed restore of the most critical system, and book it with an engineer.
- 03
Show the business
Send the risk list, with an owner against each item, to the leader who would feel a loss first.
- 04
Answer again
Repeat the assessment once the proof is done. An answer often drops first and then rises.
What do people ask before using the technology and architecture risk assessment?
Is this a security audit or a penetration test?
No. It scans nothing, tests nothing and will not find a vulnerability. It shows how much of the control you describe is located, written down and proven. A high band says your answers describe control, not that your systems are safe, so use it to decide what to examine first.
What if I am not sure our backups and run books really work?
Choose the lower answer and note the doubt as the first thing to check. The easiest error is answering from memory of the intended design, such as assuming a backup restores because the job reports success. A timed restore of a critical system is the cheapest proof.
Who should answer besides the head of engineering?
The head of engineering or lead architect can answer much of it alone, but the recovery and visibility questions are often better known to the people who carry the pager, so add an infrastructure lead. Where experienced people differ, one probably knows an unwritten control.
What does a low band tell me to do?
A low band is a reason to look, not a finding. The result picks the weakest areas by their share of points and gives steps that name the role who does them and what exists at the end, such as a timed restore record. Check your strongest answer too.
Related
Do you know which failure your business could not absorb?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.