Who may access the source code, the pipeline and the production environment?
Access control in software development concerns the question of who may perform which action on which part of your development pipeline: who may read code, who may modify and merge code, who may start a build and who may deploy a release to production. This is a more specific question than access control for an organisation in general, because a development team works with multiple systems simultaneously: a source code repository, a build and test environment, and usually a separate production environment where the software actually runs.
The reason this topic recurs in security questionnaires and in the care obligations of the NIS2 Directive is that an error in access to your development pipeline directly affects everyone who uses your software. Anyone who can undetectably modify code that is subsequently deployed affects not only your own organisation but also your customers. This is why both a supervisor and a customer who is themselves subject to care obligations ask how you have arranged this.
Why this specifically concerns the source code and the pipeline
A development team typically has more people with broader rights than strictly necessary, simply because it is practical: everyone can access everything, no one needs to wait for anything. From the perspective of care obligations, this is exactly the point where further questions are asked. Not because trust would be wrong, but because demonstrability is different from trust: a supervisor or a customer wants to know whether you can show who has access, not merely whether you trust them.
The questions that recur usually address three layers. The first is the source code repository itself: who can read, who can modify, and is there mandatory review before a change is merged with the main version. The second is the build and test environment: who can start a build, and does that environment have access to data or systems not intended for testing purposes. The third is the production environment: who can actually deploy a release, and is that a different group of people than who writes the code.
Separation between writing and deployment
A recurring distinction in questionnaires is whether the person who writes code is also the person who deploys the release to production. Where that is the same person, without an intermediate step by someone else, a situation arises in which an error or malicious change reaches production undetected. Many organisations solve this with mandatory second review before code is merged, and with a separate role or separate rights for the actual deployment. What that looks like in practice varies greatly per team and per scale; the Directive itself does not prescribe a specific method, but supervisors and customers do look at the underlying question: can one person uncontrolledly introduce changes that affect customers.
Secrets and keys separate from code
A second point on which questionnaires regularly follow up is where passwords, API keys and other secrets are stored. Secrets that are in the source code itself are visible to everyone with read access to that code, which can be a much larger group than who actually should work with that key. A separate vault for secrets, with its own access rights separate from the code repository, is a common way to separate that. Whether and how you arrange this is a technical choice; what is relevant for the dossier is mainly whether you can explain why the chosen approach is suitable for the scale and the risks of what you are building.
What you document, not only what you set up
Setting up technical access rights is one thing; being able to demonstrate it is another, and the second is more often overlooked in practice. A record of who has access to which system, when access was granted, and on what basis, is precisely the evidence a questionnaire or a supervisor asks for. Without that record, you must look it up again for each question; with a living register next to each measure, the answer is already at hand. review the explanation per measure provides an overview of how access management relates to the other nine measures from the duty of care.
Whether your organization itself falls under the duty of care, or you receive this question because a client does, can be determined with a few questions. For those wondering how strict the requirements for access management are exactly when a client asks to demonstrate what has been arranged, the explanation on data protection and security provides a broader picture of where this type of requirement comes from.
For your own situation, such as whether a specific setup of your development pipeline is sufficient for the duty of care that rests on you or your client, a lawyer or the competent supervisor is the right place; secria.eu prepares the documentation but does not make statements about individual compliance.
Would you like to see how access management fits within the rest of your dossier, or do you have further questions about what exactly is meant by this measure? read the frequently asked questions provides a short answer on many of those points, and the free quick-scan shows in a few minutes where your organization stands on this subject.