This is the first measure from article 21(2), and not by accident: everything that follows should be a consequence of what you record here. Your customer wants to see that security is a deliberate choice, not an accident.
What has to be in an information security policy?
Less than the name suggests. A usable policy for a company of up to roughly a hundred people is three to five pages: which principles you apply, who is responsible for what, which rules apply to passwords, access and working from home, and how you handle incidents.
The most important part is the last step: the board formally adopts it, with a decision or a signature. A document the IT person once wrote and that was never ratified does not count as policy in a customer audit.
What is a risk assessment, practically speaking?
An overview of what can go wrong at your end, how bad that would be, and what you are doing about it. A well-kept spreadsheet counts: threat, likelihood, impact, and per risk the decision whether you accept it or act on it. The law asks for an ongoing process, so the assessment should not be older than a year.
Start with the question of which three systems would bring your business to a halt if they failed. Those are your crown jewels, and the risks around them deserve your first attention.
Who has to be responsible for cybersecurity?
One name, in writing. That can be the director; in smaller companies it is even the logical choice, because the law already holds directors personally accountable on this subject. What matters is that the question "who is in charge of this?" is not answered with a silence.
How often do I have to revisit the assessment?
At least yearly, and beyond that at every event that changes the picture: an incident, a new system becoming critical, an acquisition, a move to the cloud, or a large customer with requirements of their own. Put the annual moment in the diary of whoever is responsible, because without a date it slides until the next audit.
Revisiting does not mean starting over. It is walking through the existing list, deciding per line whether it still holds, and adding the date and the changes. An assessment with a version history shows exactly what an auditor wants to know: that this is a process and not a document.
What happens to the risks I accept?
You record them, with who took the decision and why. An accepted risk is a legitimate outcome; the law asks for a considered judgement, not for zero risk. The only unacceptable risk is the one nobody ever weighed.
Add per case which measure you do take to limit the damage, and when you will revisit the decision. Those lines in particular turn a risk assessment into a usable document in a customer conversation: you show that you know your own weak spots and have made a choice about them. For the heaviest category, the risks that come from third parties, see assessing your own suppliers.
What does a customer want to see of this?
Three documents: the adopted policy, the most recent risk assessment and the name of the person responsible. Anyone with those three answers this block on every questionnaire in five minutes.
How does this relate to the GDPR?
The two overlap more than they differ, which is good news if you already have the GDPR arranged. Your record of processing activities tells you which personal data you hold and where it sits, and that is exactly the inventory a risk assessment starts from. Your data breach procedure is largely the same procedure as your incident handling, only with a different recipient for the report.
The difference is in scope. The GDPR looks at personal data; this duty of care looks at the continuity and integrity of your entire service. A production system that goes down without a single piece of personal data being touched is not a GDPR matter and is a NIS2 matter. In practice: build on what is already there and widen the scope, rather than putting a second regime next to the first.
This block is one of ten. Anyone who has the other nine clear as well fills in every next list in a fraction of the time.