What is new in .NET 11, and should you move from .NET 10?
A fair tour of .NET 11 and C# 15 as released on 10 November 2026, the breaking changes to read first, and a decision guide for production teams on .NET 10.
· 7 min readA customer sends a supplier questionnaire, or the insurer's renewal form arrives, or the auditor adds a line to next year's plan. Somewhere in it is a section on software: how is the system patched, who can get into it, what happens if it fails. You know the system matters. You are much less sure what to write.
That is a common position for a finance or operations director whose organisation runs on bespoke software. The person who built it may have gone, and nobody has had reason to write the answers down. This article sets out the questions that tend to arrive, the evidence that answers each one, and an honest way to respond when the evidence does not exist yet.
It is a practical guide, not a compliance standard, and it is not legal advice.
The questions that usually arrive
The wording differs, but the substance is similar from one questionnaire to the next. These are the ones we would prepare for.
| The question | What answers it |
|---|---|
| How is the software patched and kept up to date? | A list of the frameworks and components it uses, their support dates, and a record of updates applied |
| Which versions are in support? | The same list, checked against the publisher's own lifecycle pages |
| Who has access, and how is it removed? | A named list of people and accounts, with a date it was last checked |
| Where does the data live? | A short description of hosting, region and which suppliers touch the data |
| How is it backed up, and has a restore been tested? | The backup schedule and a dated record of a test restore |
| What happens if the developer is unavailable? | Who else knows the system, where the code and documentation are, and who holds the passwords |
| How are changes approved and released? | A release history showing who changed what, and who signed it off |
None of this needs a thick policy manual. Most of it needs a few short, dated records that someone can produce on request.
What good evidence looks like
An auditor or a customer's security team is looking for something specific and recent. A paragraph saying "we take security seriously" does not help them. These five records cover most of the ground:
- An inventory. Each system, what it is for, where it runs, who owns it on the business side, and who looks after it technically.
- A patch and support record. The version of the framework and key components, the date each stops receiving security fixes, and the date it was last updated. Our article on what "out of support" means explains why that date matters.
- An access list. Who can change the system, who can see the data, and when someone last reviewed both.
- A backup test log. The date a backup was last restored to a separate environment, and whether it worked.
- A release history. Two records together: the change history in source control (what changed, when, and who approved it) and the deployment log from the pipeline or hosting platform (which version went live, when, and who released it). Source control alone shows what was written, not what is running.
If you can produce those five on the day they are asked for, you are in a stronger position than many organisations.
What formal frameworks expect of software
You may never pursue a certification, but it helps to know what the common frameworks look for, because many questionnaires borrow their language. ISO 27001:2022 is the one you are most likely to meet. Its Annex A includes controls with titles such as management of technical vulnerabilities, information backup, change management, access control and configuration management. The standard itself is sold by ISO, but the control titles are widely published, for example in this list from Advisera, a compliance consultancy. Each one maps to a question in the table above.
On personal data, the ICO's guidance on security outcomes under UK GDPR says organisations should manage software vulnerabilities by using in-support software and applying software update policies. It also expects appropriate backups where losing access to data could cause harm, and access limited to the people who reasonably need it. That is the same list of evidence again, seen from the data protection side. Check the ICO's current pages before you rely on any wording, because guidance is updated.
We are not auditors, and this article does not certify anything. The point is that a small set of honest records answers most of what a framework asks, whether or not you ever sit an assessment.
When the evidence does not exist yet
Sometimes the honest answer is that the records are missing. The backup has never been test-restored. Nobody can say which version of the framework the system runs on. The access list lives in one person's head.
Say so, plainly, and attach a plan. A reply such as this is respectable and tends to be received well:
We have not yet carried out a documented restore test for this system. One is scheduled for the end of next month, and we will share the record when it is done.
Questionnaires are read by people who see a lot of them. A dated commitment with an owner reads better than a confident answer that falls apart when someone asks for proof. Never describe a control as in place when it is not: the cost of being caught is much higher than the cost of an honest gap.
Closing the gaps in order
If several answers are missing, the order matters. This one works for most systems:
- Find out what you have. Write the inventory first. Every other answer depends on knowing which systems exist and who owns them.
- Check support status. Find the framework version and its end-of-support date. This is usually the question with the biggest consequences, and the date is public.
- Prove you can recover. Run a restore test and keep the record. It is one of the few controls that catches a failure before it matters.
- Tidy access. Review who can get in, remove what is no longer needed, and write down the date.
- Put changes on the record. Make sure code lives in source control owned by your organisation, and that releases go through a pipeline that logs each deployment, so the release history exists and survives a change of supplier.
- Name the backup person. If only one individual understands the system, record that as a risk and decide what to do about it. Our guide to the first week after a developer has gone covers the first moves.
You can usually do the first three within a few weeks, and they cover the questions that carry the most weight.
A sensible first step
Pick the system that appears most often in questionnaires and try to answer the seven questions in the table, in writing, using only records you can produce today. Mark each one as evidenced, partly evidenced or missing. That page is useful in its own right: it tells you where to spend effort first, and it becomes the start of your answers to the next questionnaire.
If it turns out the records are thin, that is normal and fixable. A software health audit reviews one system and reports on support status, security exposure, tests, hosting, backups and what depends on individuals, in plain English. If you would like a named engineer to keep those records current month by month, that is what software care is for.
