Security Requirements

• The list is deliberately kept short so that it can be used in Agile/Scrum as a Ready and Done criterion. If I can't immediately see how to implement these requirements for a backlog item, then at least a discussion in Refinement is called for.
• There are always reasons to make different decisions, both regarding do's and don'ts. Perhaps you have your own user management system aka identity and access management for historical reasons . In my opinion, user management is a commodity these days. If no suitable system is available, you simply install something like Active Directory. But listing the requirements for user management for every application doesn't make sense. For such specialized applications, you should look elsewhere.
• Depending on the environment, there may be additional security-related requirements. For example, when using email, DomainKeys Identified Mail (DKIM) is also important. This must then be included as a functional requirement. And even though many of the requirements are derived from data protection (especially Article 32 GDPR), to properly implement data protection, you also need to consider retention periods and deletion, information, consent, and pseudonyms — this goes deep into the application's functions.
• The same applies to the availability required by data protection or the Information Security Management System (ISMS). To ensure availability in distributed systems you have to familiarize yourself with the CAP theorem and tailor its application and data storage accordingly. This cannot simply be retrofitted to an existing application.
• In specific customer projects, there are details for each requirement — these usually depend on the specifically implemented Information Security Management System (ISMS). Many of the requirements can also be derived from IT-Grundschutz — but unfortunately, they are often spread across multiple modules. Incidentally, this list of security requirements is also compliant with IT-Grundschutz; it addresses APP.6 A2/APP.7 A4 as well as essential parts of APP.6 A3/APP.7 A3. Apparently, the Federal Office for Information Security — Bundesamt für Sicherheit in der Informationstechnik (BSI) — is also aware that no developer can read and interpret all of the modules together consistently.
• The implementation of many requirements is best achieved when there is a reference solution or reuse component. This is especially important for don'ts — developers not specifically trained in security will fail at encryption or XML validation — as we have experienced many times in practice.
• If there are reasons to deviate, then the reasons and the alternative solution should be documented. Ideally, you should consult with a security expert and conduct threat modeling . And, of course, serious threat modeling requires that you have defined security requirements. Ultimately, you can immediately draw conclusions about the risks from unmet requirements.

Authentication, Authorisations, Auditing

• Use single sign-on mechanisms to authenticate users (do)
• Use X.509 certificates or Kerberos to authenticate systems or services (server and client) (do)
• Do not implement your own authentication mechanism (don´t)
• Use an authorization concept suitable for the process (procedure) (do)
• Use an audit/logging concept that is appropriate for the process (the procedure) and compliance requirements (especially data protection logging requirements) (do)

Encryption

• Use only https, TLS, or (if necessary) ssh to transfer data (do)
• Use (transparent) encryption for stored data (e.g. full disk encryption) (do)
• Do not implement any encryption methods or digital signatures yourself (don´t)
• Do not implement end-to-end encryption (don´t)

Input Validation and Output Encoding

• Implement meaningful input validations for the process (the procedure) — Input validations for the process are almost always stricter than validations for safety only and thus also improve usability (do)
• Avoid XML and other container formats (don´t)
• Use appropriate output processing methods (do)
• Use a suitable session concept (do). Don't implement your own session management (don´t)

Secure Configuration and Exception Handling

• Clean Code, DRY, YAGNI, KISS (do)
• Automatic updates up- and downstream (do)

Test Automation

• All security requirements (except the don'ts) can and should be tested automatically (do)