Maatregelen
DS.1.001. Classification of Processing Activities
Description
Last updated: 30-10-2020
All information processing activities have an owner, the process owner.
All processing activities need to be registered and maintained, this is the responsibility of the process owner.
All processing activities need to be classified to determine the potential impact to the organization.
The CISO Office will publish and maintain a classification procedure.
Classifications are updated every 2 years or when major changes to the processing activity warrant re-classification.
Technical specification:
On this page (internal) it is explained how to add processing activities to the processing registry. Classification is a part of that process.
DS.1.002. Registration of Processing Activities
Description
Last updated: 30-10-2020
All processing activities (with and without PII) need to be registered and maintained, this is the responsibility of the process owner.
The registration contains at least the classification of the processing activity, the process owner and a description of the IT services used for the activity.
Technical specification:
On this page (internal) it is explained how to add processing activities to the processing registry. Classification is a part of that process.
DS.1.003. Usage of Suitable IT
Description
Last updated: 30-10-2020
IT services used in the processing activity are considered suitable according to their communicated IT Security Capability level.
Operating procedures for correct and secure usage of the IT services, delivered by the service, are followed.
The IT service offers appropriate functionality for uptime (Recovery Time Objective) and backups (Recovery Point Objective) for the data processing activity.
Technical specification:
When processing information, you normally make use of 1 or more IT services. For example, you could receive information in your email, store it locally on your managed laptop, modify it in an application and upload it to SharePoint. Each of the services you use needs to be appropriate for use.
What is appropriate is determined by the classification of the processing activity and the Security Level of the services you are using. UU services should be offered with a specific Security Level.
DS.1.004. Usage of Organisationally Managed Systems
Description
Last updated: 30-10-2020
Data processing activities should be processed and stored exclusively on organisationally managed (either contracted or governed by the organisation) hard-and software.
Technical specification:
Use only official UU managed hardware and supplied facilities to process Critical information.
DS.1.005. Responsible Emailing
Description
Last updated: 08-09-2022
Users should adhere to internal best practices regarding email to avoid causing data breaches, to limit the impact in case data breaches happen. and to support forensics and impact if a data breach does happen.
Technical specification:
DS.10.001. Signed Non-Disclosure Agreements
Description
Last updated: 30-10-2020
Before processing sensitive data, individuals working with the data must agree to non-disclosure agreements that limit the legal room for distributing the data during and for a period after the activities take place. NDA’s also specify consequences of breaches of the agreement and are signed by the individuals.
Technical specification:
UU contracted employees adhere to the Code of Conduct that states they will treat information with the appropriate care and keep it secret. So if you only work with UU colleagues, you do not need NDA’s. If you work with external parties though, make sure they are contractually obligated to keep sensitive information secret.
Contact HRservicedesk@uu.nl for help with NDA’s for contractors.
DS.11.001. Team Capacity Monitoring
Description
Last updated: 30-10-2020
Teams plan to have sufficient capacity to execute important tasks, also during holidays. There is monitoring on the capacity of the team and structural understaffing gets flagged and addressed. There are procedures in case of unplanned absence of team-members to continue with important processes.
Technical specification:
–
DS.11.002. Key Personnel Management
Description
Last updated: 30-10-2020
Individuals in teams that are the only ones capable of performing specific tasks need to be identified as Single Points of Failure. Team leaders are responsible for identifying these individuals and transferring this knowledge to other employees and procedures. If this knowledge is non-transferable, more capable staff or a retainer with a supplier that can provide this expertise needs to be arranged.
Technical specification:
–
DS.12.001. Encrypted Portable Storage
Description
Last updated: 17-8-2020
Data stored on portable storage devices is stored encrypted according to modern standards.
Technical specification:
Encryption of portable storage must follow the Dutch NCSC advice for bulk data encryption as described in the guideline on TLS, which can be found here: https://www.ncsc.nl/documenten?trefwoord=TLS%20versleuteling .
UU offers tools that are considered suitable, when used right, for the encryption of data on portable storage devices. See this page for an overview of services (encrypted USB/HDD, winzip with right settings, BoxCryptor, Bitlocker, ….). See this intranet page for more on encrypting your information: https://intranet.uu.nl/informatiebeveiliging-hoe-ga-ik-om-met-externe-harddisks-en-usb-sticks .
DS.12.002. Terms of Use for Data & Access
Description
Last updated: 30-10-2020
For the processing of data other than the primary process for which this data is collected, Terms of Use and agreements are available that detail how the data can and must be treated, also for internal processes. These Terms of Use have to be agreed to before the processing of data and the data owner remains responsible for the data and monitoring that the Terms of Use are adhered to.
Technical specification:
Data-owners are responsible for the data and remain so, even after granting access to others. This can be the case for developing new software or for research purposes. It is important that there are clear agreements on how data is handled when data classified as Critical on C-I-or -A is shared with others outside the process itself.
These agreements should look a lot like a Data Processing Agreement and contain many of the same clauses, such as how the information is secured and how incidents are treated.
DS.12.003. Signed Data Transport
Description
Last updated: 5-6-2020
The identity of receiving and originating party is verified using (digital) signatures.
Technical specification:
Digital signatures must use cryptographic standards and public/private keypairs to sign documents, so they cannot be repudiated or tampered with.
S/MIME may be used for digital signing/verification. Contact secops@uu.nl for help with setting up your data transport in a secure manner.
DS.13.001. Suppliers & Partner Information Security
Description
Last updated: 30-10-2020
Suppliers are contractually obligated to adhere to the information security policies of the UU. All agreements made with the supplier apply to sub-contractors equally and are under the responsibility of the supplier.
Agreements with partners (including external researchers) include appropriate data management and security controls for the classification of the processing activity.
Technical specification:
–
DS.13.002. Validation of Supplier Information Security
Description
Last updated: 30-10-2020
Before new suppliers of Information Technology products or services are contracted or engaged for the purpose of supporting processing activities with this classification or higher, official advice must be requested on the Information Security risks as seen by the CISO Office. The CISO Office can request additional documentation, certifications or conversations with the supplier to formulate a non-open-ended advice whether or not we can continue with this supplier or under what circumstances.
Technical specification:
Before a new service is contracted or used, follow the steps outlined on this page to make sure that information security risks of the supplier and the product are identified.
DS.13.003. Supplier Data Access
Description
Last updated: 30-10-2020
Supplier is contractually disallowed from accessing organisational data in any other way than upon specific request of the organisation. This request must be demonstratable and actions taken by supplier logged.
Technical specification:
–
DS.13.004. Supplier Incident Management
Description
Last updated: 30-10-2020
Contractually, suppliers are obligated to inform the UU of any breach to their information security that could potentially affect the UU as soon as possible but at least within 72 hours of establishing the incident.
Technical specification:
–
DS.13.005. Supplier Vulnerability Management
Description
Last updated: 30-10-2020
Contractually, suppliers are obligated to inform the UU if vulnerabilities are found in contracted IT services. This notification does not need to include technical details, but at least contain an indication of the risk to the UU due to the vulnerability, expected timelines for addressing the vulnerability, a comprehensive overview of steps the UU can take to mitigate the risk posed by the vulnerability and if there are indications the vulnerability has been abused.
Contractually, in the event of indications of compromise, supplier is obligated have digital forensics performed by an independent party to determine the extent to which UU data has been exposed or compromised.
Technical specification:
–
DS.13.006. Monitoring & Auditability
Description
Supplier will provide periodic reports to show that agreements and service levels are attained.
Suppliers will allow and facilitate the UU to perform audits to ascertain that the contractual agreements with regards to information security are adhered to and to gain further insight into information security risks related to the continued usage of the IT service or product.
DS.13.007. Proven Supplier
Description
Last updated: 30-10-2020
Supplier has existed for at least 3 years.
Supplier must have a proven solution in use at other organizations for comparable use cases. Supplier is able to give references that can be contacted regarding their use of the supplier’s solution.
Supplier can demonstrate measures taken to guarantee continuity of business operation.
Technical specification:
References from successful implementations for comparable use cases are contacted to ask for their experience with the product and supplier.
Measures to account for business continuity may include a large enough workforce with knowledge of the solutions and tools, extensive documentation, separate holdings for intellectual property and financial flows.
DS.13.008. Certified Supplier
Description
Last updated: 30-10-2020
Supplier is appropriately certified for information security by an independent third party auditor. The certification is a maximum of 2 years old.
Technical specification:
For ISO27001 certification the SoA needs to be confirmed by UU information security.
ISAE3402 statements are not sufficient for Information Security.
informatiebeveiliging@uu.nl determines if a certification and its scoping is sufficient for the intended services to be delivered by this supplier.
DS.13.009. Data Portability
Description
Last updated: 30-10-2020
Supplier is contractually obligated to deliver the UU data in a convenient and portable format on request.
Technical specification:
–
DS.14.001. Data Retention Period
Description
Last updated: 30-10-2020
Data has an identified and recorded period of time for which it is retained and available, which is set to the minimum of legal and business requirements. After this period, data is deleted and unrecoverable. Data deletion for different storage mediums must occur in line with the NIST standard for data deletion level ‘Clear’ or higher: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf.
This includes sensitive data stored hardcopy which needs to be properly shredded and destroyed.
Technical specification:
–
DS.14.002. Data Archiving Procedure
Description
Last updated: 30-10-2020
There is a data archiving procedure detailing how certain documentation that may be needed beyond the data retention period can be archived. Note that archiving is a one-way procedure and meant for long-term storage in read-only repositories.
Technical specification:
–
DS.14.003. Data Destruction Declaration
Description
Last updated: 30-10-2020
When critical data is destroyed (either digitally or the storage medium), a declaration of data destruction has to be signed by the person executing the destruction that includes the identity of the destroyer, the date, the method used to destroy and a signature that destruction took place.
Data destruction declarations are stored and copies available on request.
Technical specification:
–
DS.15.001. Staff Involved in Risk Identification Workshop
Description
Last updated: 30-10-2020
At least once every year, a workshop takes place with staff of the services to identify potential risks, attack vectors or improvements. Where possible, suppliers of supporting IT services are included in the workshops. The outcomes of the workshop are documented and identified risks are treated according to existing Risk Management practices. Recommendations to improvements to baselines are shared with the CISO Office.
Technical specification:
–
DS.15.002. Incident Communication Policy
Description
Last updated: 17-8-2020
After incidents are established, the University communicates as openly and truthfully to affected parties/subjects as is permissible without sharing details of active vulnerabilities.
At least this communication details the extent of the incident, the suspected causes, the steps taken to mitigate risks, what will be done in the future to prevent further incidents and what people can do themselves to further reduce their risks. Furthermore, contact details of the organisation will be given for questions regarding the incident.
Technical specification:
For data breaches involving personal data, see this page on what to do regarding communicating to data subjects: https://intranet.uu.nl/datalek-melden-aan-betrokkenen .
DS.15.003. Business Continuity Management
Description
Last updated: 30-10-2020
Critical processes are identified and there are plans for how to proceed under conceivable crisis-situations such as non-availability of supporting IT services. These plans are tested, and revised and updated every 3 years.
Technical specification:
–
DS.16.001. Change Management
Description
Last updated: 30-10-2020
Changes to processes are evaluated for security impact. There will be checked if there are reasons to update the classification of the data processing activity and appropriate measures are taken.
Technical specification:
–
DS.16.002. Security in Projects
Description
Last updated: 5-6-2020
Projects reserve sufficient time, manpower and budget to assess and adhere to information security policy.
Technical specification:
A rationale for the reservations for security needs to be present. Without a rationale, a 5% of project budget for security and privacy is a recommended minimum.
DS.2.001. Secure Working Training
Description
Last updated: 30-10-2020
People must receive instructions and training on how to work securely using most common organisational IT services before processing data.
Technical specification:
As a manager you need to ensure that individuals working under you have received the right instructions and training to perform their work activities in a secure manner. When in doubt, contact informatiebeveiliging@uu.nl about training options.
DS.2.002. Secure Behaviour
Description
Last updated: 30-10-2020
Everyone working with UU data consistently demonstrates secure behaviour.
Technical specification:
Secure behaviour includes at least the following:
• Knowledge and awareness of policies
• Follow University Information Security policy
• Knowledge of who in the organisation can be contacted for help
• Alertness and reporting of phishing and suspicious behaviour
• Reporting of data breaches and security incidents (also on personally owned hard- and software if it contains organisational data)
• Approach and inform colleagues when they demonstrate unsafe behaviour
All (suspected) information security incidents are reported to CERT at cert@uu.nl. Follow-up steps suggested by CERT to mitigate the damage will be followed.
Description
Last updated: 30-10-2020
Data can only be moved to hardcopy with express permission of the data owner.
Information Security policy and controls are equally applicable to hardcopy data.
Technical specification:
Do not print critically sensitive information, unless you have explicit permission to do so. You need to treat printed information as secure as digital information.
DS.2.004. Security Awareness Review
Description
Last updated: 30-10-2020
In performance reviews, secure behaviour is discussed and part of the evaluation.
Technical specification:
Managers should make sure that working securely and attentively is something that is monitored and part of feedback. Reporting of (potential) risks and incidents should never be punished but rewarded and motivated, and are part of a positive review. Demonstrating the behaviours listed in DS.2.002 should be actively encouraged.
DS.2.005. Appropriate Handling of Information
Description
Last updated: 30-10-2020
Information is only distributed to people that have a legitimate need for it. Authentication details and tokens are never shared (not to colleagues or secretarial staff). Only the minimum amount of information that is needed for a purpose is shared, through channels appropriate for the level of data classification.
Technical specification:
Do not share credentials, logins or unnecessary information from your applications with anyone. This includes colleagues that may have to perform certain tasks or favours for you, use appropriate ways to achieve those goals.
DS.2.006. Social Media Policy
Description
Last updated: 30-10-2020
The organization has a social media policy. The CISO Office is consulted for the policy to address security aspects.
The Social Media policy distinguishes between acceptable and representative uses of Social Media for private use, and how Social Media representing the organization must be managed.
Social Media software is subject to the Information Security policies.
All individuals are informed of and adhere to the Social Media Policy.
Technical specification:
Remember when using Social Media that you are considered a representative of the organization. When in doubt whether statements may be considered offensive, local communication experts can always be consulted.
Scraping Social Media is a data processing activity that should not be performed without following the necessary steps listed in DS.1.002 and having performed the necessary Privacy checks.
DS.2.007. Learning From Incidents
Description
Last updated: 30-10-2020
Where there are repeated security incidents, lessons will be drawn and the source of (repeated) incidents addressed in a structural manner, changing processes and supporting IT where appropriate.
Technical specification:
It can always happen that something goes wrong by accident, but if a process goes wrong in the same way multiple times, that is a good reason to critically evaluate if there are other ways to perform this process. If assistance is desired in seeing if there are more secure (and often more efficient) ways to perform a process, please consult informatiebeveiliging@uu.nl
DS.3.001. Clear Screen
Description
Last updated: 5-6-2020
Individuals are responsible for maintaining a clear and secure digital working space. This means no text files with passwords or sensitive information, cleaning up data and archiving historic data appropriately and no installing of excessive programs and tools.
Individuals that work from public locations use privacy screens when accessing information.
Technical specification:
Keep your screen clear and be aware of your surroundings and who may be able to see what you are doing. If you frequently have to work with sensitive information in (semi)-public spaces, consult with your manager if you can obtain a ‘privacy-screen’ for your laptop.
DS.3.002. Lock Screen
Description
Last updated: 30-10-2020
All systems and devices that are not actively manned and used, need to be locked when leaving the working space unattended.
Technical specification:
Windows key + L, or Ctrl + Cmd + Q on Mac.
DS.3.003. Physical Protection of Information in Working Spaces
Description
Last updated: 5-6-2020
Information is stored appropriately in locked cabinets in working spaces.
Physical working spaces not intended to be open and publicly accessible need to be secured appropriately.
Technical specification:
For non-public workspaces, University buildings need to be protected according to the appropriate operational standards of UU FSC Security, corresponding to “Standard Area” or higher.
Contact FSC security via Topdesk if you wish to check if your working space is appropriately secured.
DS.3.004. Enhanced Physical Protection of Information
Description
Last updated: 30-10-2020
Information carriers, the working spaces and personal physical security are all appropriately protected, in accordance with UU FSC Security.
UU areas where processing activities take place are reported to UU FSC Security for appropriate physical protection of assets and people involved in the activity.
Technical specification:
Contact FSC security via Topdesk if you wish to check if your working space is appropriately secured.
DS.3.005. Clear Working Space
Description
Last updated: 30-10-2020
Desks and working spaces should be void of sensitive information, documents and portable data storage devices. This includes post-its with passwords, documents and equipment lying around.
Technical specification:
Clear your desk and working space after you are done. This applies both to the office environment and your home environment. Note that a regular locked door in the office is not sufficient protection for the information in that room. Put sensitive information under lock and key that only authorized people have access to.
DS.4.001. Identification
Description
Last updated: 30-10-2020
Before commencement of processing activities all individuals working with data and systems have been identified using a nationally issued Identification Document.
Technical specification:
All contracted UU employees and contractors have had their identities validated before accounts have been provisioned. So if you work with UU colleagues, this has already been taken care of. However, if you work with people from outside our organisation, make sure their identities have been sufficiently validated before you exchange information.
DS.4.002. Background Check
Description
Last updated: 5-6-2020
Before commencement of processing activities all individuals working with sensitive data and systems have basic background checks performed to determine integrity, suitability for the tasks and secure behaviour.
Technical specification:
At least 2 references are confirmed and contacted before the start of employment to attest to the integrity and qualities of the candidate.
Personnel is required to deliver a VOG (Dutch for: Verklaring Omtrent Gedrag, Declaration about Behaviour) covering relevant criminal history to this processing activity, or an international equivalent from local law enforcement.
A new VOG is required every 5 years. If a VOG cannot be obtained, the processing activities need to be ceased and the access of the individual revoked at first opportunity.
DS.4.003. Extensive Background Screening
Description
Last updated: 30-10-2020
Background verification is performed through a trusted third party that involves extensive screening for financial, national, criminal and other relevant factors that could influence the integrity and reliability of personnel before processing activities start. Background screening needs to be repeated every 10 years. If a screening finds issues, processing activities and access need to be revoked immediately and treated as a potential incident.
Technical specification:
We need to ensure that the integrity of people working in Critical roles is appropriate for their critical access. Contact HR and informatiebeveiliging@uu.nl to determine the appropriate level of screening.
DS.4.004. Visible Organizational Identity Cards
Description
Last updated: 5-6-2020
In areas designated only for employees only, employees should be clearly recognisable, carry their corporate identification card visibly and be able to demonstrate said identification upon entry and on request in the working area.
Technical specification:
UU campus cards must be worn visible in locations designated for employees only. Contractors and guest must wear a visible guest card.
DS.4.005. External Visitors to Non-Public Spaces
Description
Last updated: 30-10-2020
Non-contracted visitors into non-public areas are always accompanied by UU staff.
There must be a procedure for employees from contracted partners to commence activities on site. This procedure includes that contractors must be announced beforehand, identified, be clearly recognisable while performing work.
Technical specification:
If someone visits you, make sure that you are always with them as they navigate non-publicly accessible areas.
When a supplier sends out people to perform activities in non-public spaces, they need to register these activities with us before they start, so that we can validate anyone trying to gain access to non-public locations is authorized for that. Contact FSC Security (Tel: 4444) if you suspect someone may not be authorized to be in this location.
DS.5.001. Espionage and State Actor Monitoring
Description
Last updated: 30-10-2020
Organisational processes and research that may attract Nation State actors or Corporate Espionage need to proactively monitor for signs indicative of ongoing intelligence activities, and take additional and tailored actions to protect against potential threats.
Technical specification:
When there is potential threat of espionage, appropriate measure must be taken in consultation with the CISO Office, UU Security Operations and UU FSC Security.
DS.5.002. Personnel Threats
Description
Last updated: 30-10-2020
Threats to the (online) security of affiliates of the University are reported to cert@uu.nl and appropriate custom protective measures are taken to address the risks.
Technical specification:
–
DS.5.003. Travel to High Risk Countries
Description
Last updated: 17-8-2020
When travelling to certain countries, appropriate additional information security measures must be followed.
Technical specification:
The CISO Office will monitor a list of countries for which negative travel advice with regards to data security is published. This list will be made known and published to the organisation. There will be tailored and specific advice and facilities to support data security during travel to these locations.
See this page for advice on travelling to high-risk countries: https://intranet.uu.nl/informatiebeveiliging-reizen-naar-het-buitenland
DS.7.001. Access Approval
Description
Last updated: 30-10-2020
Data should have a data owner. Access to data can only be given after approval of the appropriate data owner (which can be mandated or given based on roles, as long as this is documented).
Technical specification:
–
DS.7.002. Registration of Access Requests / Revocations
Description
Last updated: 30-10-2020
The requests of individuals that want access to information assets or authorisations to do so are logged and kept for at least 1 year. It includes the requester, and the approval (or rejection) of the appropriate data owner. Revocation requests, end of employment notifications and changes are recorded and kept for at least 1 year.
Technical specification:
–
DS.7.003. Access Revocation on Changes
Description
Last updated: 30-10-2020
After role changes or upon termination of contractual or formal relations between the organisation and the individual, access to data that is no longer part of your role is revoked at first opportunity.
Technical specification:
–
DS.7.004. Access After Changes
Description
Last updated: 30-10-2020
If revocation of access takes place after the date access was no longer needed according to the data owner (applicable to both role changes and termination of relations), logs must be inspected to determine if inappropriate actions have been performed during this window. If so, this is treated as a security incident. The outcome of the inspection is logged.
Technical specification:
–
DS.7.005. Returning Data and Equipment
Description
Last updated: 30-10-2020
When data carrying devices or sensitive data is given to employees, they must sign for the appropriate handling. This information must be logged in personnel files. Equipment and data must be returned upon termination or role changes. Successful intake of data and equipment shall be registered in personnel files.
Technical specification:
Responsibility of manager or the individual that contracted services. Personnel files are the best location to store agreements and sign-offs that equipment has been returned.
DS.7.006. Access to Data in Special Cases
Description
Last updated: 30-10-2020
In exceptional cases, such as the unexpected death of employees or contractors, access to data that has not yet been deleted can be requested by people other than the data owner or individuals who had already been granted access.
The process owner for the data must have a documented procedure available for this which is approved by the CISO Office and the DPO.
Technical specification:
If no other documented and approved procedure is available, the protocol for deceased employee is applicable to all cases of Access to Data in Special Cases. Contact informatiebeveiliging@uu.nl to follow this procedure.
DS.9.001. Staged Warning Model
Description
Last updated: 30-10-2020
Upon noting deviations from information security policy and inappropriate handling of data, initially an informal warning will be given by the supervisor. If a second case presents itself within a year, a formal warning will be given and logged in personnel files. If within a year of the last formal warning a new situation presents itself, a final formal warning will be given. If within a year of the final formal warning a new situation presents itself, the case will be presented to a committee consisting of representation of the Organizational Unit, CISO and HR that will determine the disciplinary action.
Technical specification:
–
DS.9.002. Official Charges
Description
Last updated: 30-10-2020
Police reports will be filed when willfully breaking of the law or actions with criminal intent are ascertained with regards to data handling. A record of this will be placed in the personnel file. The case will immediately be presented to a committee consisting of representation of the Organizational Unit, CISO and HR that will determine the disciplinary action.
Technical specification:
–
IS.01.001. Security Capability Level
Description
IT services are offered with a specific security-capability level (Dutch: geschiktheidsniveau). The IT Security controls for that level are applicable to the IT service.
The security capability level of the IT service is documented in the IT service description and communicated to end users through the IT service catalog, so they can use appropriate services for their data processing activities based on classification.
Information Security Advisory ITS initiates verifications to see if IT services have correctly implemented the appropriate controls.
Technical specifications
The Security Capability Level is expressed as a Classification for Availability, Integrity and Confidentiality. The score indicates what the maximum level of classification of a processing activity can be that uses this IT service.
The Security Capability Level is determined by following the steps listed at: https://intranet.uu.nl/geschiktheidsclassificatie-voor-it-dienstaanbieder
Rationale
Security Capability Level ensures that IT services are used only for information processing activities that match their intended security posture. By assigning each service a defined capability level aligned with the required levels of availability, integrity and confidentiality, the organization establishes a clear boundary for the types of information and processing activities that can safely occur within that service.
Communicating the capability level to end users provides them with the insight needed to select appropriate IT services for their data processing needs and prevents the accidental use of systems that do not provide sufficient protection for sensitive information. This reduces the risk that confidential or critical information is processed in environments that do not meet the required security controls and safeguards.
Verification by the Information Security Advisory function ensures that IT services have implemented the security controls associated with their capability level. This oversight provides assurance that services remain aligned with organizational information classification requirements and that security expectations are consistently applied.
By aligning service capability levels with information classification principles, the organization ensures that IT services support secure data processing, reduce the risk of processing information with a higher classification level in services that do not provide the required protection, and maintain a controlled and transparent security baseline across the IT service landscape.
External reference
A.5.12 Classification of information (direct), A.5.13 Labelling of information (communicatie van classificatieniveau), A.5.9 Inventory of information and other associated assets (service als asset)IS.01.002. Asset Registration
Description
Organizationally owned assets are registered with their relevant lifecycle status, an asset owner (by role) and a classification of the information asset. At a minimum the following hardware and software assets used in the processing of information are registered:
• (portable) data storage
• media (including hardcopy)
• portable and fixed processing units
• connected peripherals
• network equipment
• user accounts
• operating systems
• packaging and administration software
• business applications
• scripts and automations
• certificates and keys
• suppliers
• physical locations relevant to the IT services (including datacentres
Technical specifications
A Configuration Management System is used, where individual Configuration Management Databases (CMDBs) are integrated into a holisticn overview of IT assets.
Rationale
A current and reliable inventory of IT assets forms a fundamental prerequisite for effective information security management. Without visibility into which systems, applications, accounts, and infrastructure components exist within the organisation, it is not possible to consistently apply security measures or properly assess risks. Registering assets, including ownership, classification, and lifecycle status, supports governance, risk management, and responsible management of IT services.
Assets are therefore centrally registered within a Configuration Management System in which Configuration Management Databases (CMDBs) are integrated. This provides visibility into dependencies between IT assets, enabling administrators and security teams to determine which systems may be affected by maintenance activities, configuration changes, or security incidents.
An incomplete or inaccurate asset inventory may result in unmanaged systems, forgotten accounts, unpatched software, or unknown dependencies between IT components. By systematically registering all relevant IT assets, a reliable foundation is established for security practices such as patch management, vulnerability management, and access control.
Compliance with this measure is ensured through clearly defined asset ownership responsibilities, the use of central configuration management systems, and periodic reviews of the completeness and accuracy of the asset inventory. Integration with change management, monitoring activities, and audit processes ensures that changes to the IT environment are consistently recorded and controlled.
External reference
ISO/IEC 27001:2022 Annex A - A.5.9 Inventory of information and other associated assets (Primary), A.5.12 Classification of information, A.8.9 Configuration managementIS.01.003. Periodic Check of Asset Registration
Description
The topicality of registered information assets is checked yearly. Results of the checks are documented and stored.
At least once every 2 years potentially missing assets are located and updated.
Technical specifications
An asset management audit process is in place and executed yearly, the results are administered in a GRC tool.
Rationale
A reliable asset inventory is a fundamental prerequisite for effective information security management. When asset information is not regularly reviewed, there is a risk that systems, applications, or other IT assets remain incorrectly or incompletely registered. This can result in unmanaged systems, unclear ownership responsibilities, or missing security controls.
Periodic verification of registered information assets ensures that asset information remains accurate and complete. These reviews enable organisations to identify changes in the IT environment, such as newly introduced systems, removed components, or modified dependencies, and to update the asset inventory accordingly.
In addition, periodic searches for potentially missing assets reduce the risk of unmanaged or “shadow” assets existing outside formal management processes. Such assets may introduce vulnerabilities and reduce organisational visibility into security risks.
By implementing a formal asset management audit process and recording the results in a GRC tool, the organisation strengthens governance, compliance, and auditability. This ensures that the asset inventory remains up to date and that discrepancies are identified and corrected in a timely manner.
External reference
ISO/IEC 27001:2022 Annex A – A.5.9 Inventory of information and other associated assets (Primary), A.8.9 Configuration managementIS.02.001. Privileged Access
Description
Privileged Access involves all access that exposes more functionality than regular users have on any layer of the IT service infrastructure. Authorizations for privileged access are required to follow all principles governing authorisations from the Knowledge and Data Security controls, including Least Privilege (just-enough admin).
Privileged Access is just-in-time, meaning it is only used for when needed and regular user actions are not performed using the privileged account.
Privileged access is demonstrably limited to authorized personnel, an authorization matrix is available for this access.
Technical specifications
Personal privileged access to systems is done with a personal privileged account. Types of privileged access, that are separate duties, have different personal privileged accounts. Non-personal privileged access is done using non-personal privileged accounts (see IS.2.002).
Authorizations assigned to privileged accounts are based on the principles of segregation of duties, and least privilege.
Role based access management is used. Roles are defined based on tasks, responsibilities and privileges aligned with the procedures in place for the processes handled within the system.
Personal privileged accounts are disabled as soon as the user no longer requires the permissions or account to perform their duties.
Non-personal privileged accounts are set up for a specific task and are disabled/removed when that task is no longer performed. Non-personal privileged accounts are not reused in different applications and services. Example: Do not reuse a database service account for printer management.
Reviews are done to find and disable unused privileged accounts according to classification levels:
Basic: Yearly
Sensitive: Quarterly
Critical: Monthly
Privileged assets are managed using Privilege Access Management (PAM) tooling. Changes are administered using a CMS/ITIL tool with complete audit logging.
External reference
ISO27002: 5.15IS.02.002. Service Accounts
Description
Service account are only used when necessary for system authentication (no association with natural persons) or system-to-system authentication. The purpose of a service account always needs to be documented. Each unique application to service link should have a unique service account.
Service Accounts are never used to perform actions as natural persons.
Service Accounts are configured according to Least Privilege and, where used, have stronger password complexity requirements than regular accounts. Where possible passwordless authentication is used for service accounts.
Regular user account can only be used to automate tasks for the individual user and not for generic processes.
Changes to service accounts are performed according to 4-eyes principle. Service accounts are registered in the CMDB and have an owner.
Abuse cases of service accounts are identified. There is active security monitoring of service accounts with more privileges.
Technical specifications
Password domain policies are configured for the various roles of service accounts. Every supported platform has a device management tool to check and enforce the policies automatically.
Where passwords to service accounts do need to be stored, the UU password policy is applicable to service accounts with the following exceptions:
• Minimum of 20 characters
• Password rotation at least every 2 years
Stored in a password vault with encryption and MFA
• When individuals that had access to service accounts change their employment with the organization, service account passwords they had access to need to be rotated
IS.02.003. Separate Accounts for Privileged Access
Description
Accounts for privileged-personal use are separate from personal-non-privileged accounts. If a user needs privileged functionality, a second privileged account will be issued to keep the privileged and non-privileged activities separated.
Personal-use privileged privileges are Just-in-Time, meaning they are only provided when needed and the privileges are revoked after they are no longer required.
Technical specifications
Privileged accounts are centrally managed.
MFA is required as defined in IS.2.006.
Personal privileged accounts must make use of the UU password policy for personal privileged accounts as defined in IS.9.002.
If a privileged account has not been logged into for a year, it is disabled. It can be re-enabled by request and only after re-identification of the user.
In the UU there are three types of personal privileged accounts:
• Workstation admin accounts
o Can only login to workstations
• Server admin accounts
o Can only login to servers
• Application admin accounts
o Can only login to applications.
A user might have the need for more than one of these. They are split for risk mitigation. When one type of privileged account is compromised, it limits the effects a malicious party can have on UU services.
It is allowed, for reasons of security like conflict of interest or separation of duties, to split privileged account types into subtypes. For example a domain administrator needing a separate domain administrator account and another account for server admin work.
IS.02.004. Session Management for Privileged Access
Description
Privileged Access to IT services is orchestrated through a session management system.
Actions taken using privileged accounts are logged or recorded. These actions are reviewed (either sample-based or systematically).
Credentials to privileged accounts are not exposed to end users.
When passwords are used instead of cryptographic keys or passwordless authentication, passwords are rotated automatically (one-time-use passwords) at the end of the session.
Technical specifications
One can request a connection to Splunk to realize central logging and auditing.
IS.02.005. Break Glass Procedure
Description
There is a procedure to use Privileged Access Management in unpredicted and/or emergency situations when access to privileged accounts is required in unanticipated events (privileged or nonprivileged). Passwords are rotated every time when the break the glass procedure is carried out.
A Break the Glass (BtG) account is an account that is never used, unless normal way of access to the system is unavailable.
The CISO and Process Owners are informed of any usage of the break the glass procedure. The process owner approves use of BtG accounts.
Technical specifications
BtG accounts need to have the following setup:
-MFA should be disabled
-Password length should be at least 16 characters
-The BtG accounts are not federated
-The password shall not expire
-The password is split in two and stored, in sealed bags, in two different physical locations.
-The sealed bags are stored in fire-resistant vaults.
-Access to the vaults is set up that not a single person has access to both vaults.
-At least two people should have access to each vault.
-The rest of the password needs to adhere to the passwords requirements, as described in IS.9.002.
The following activities of all BtG accounts are logged and should be monitored by UU ITS Security Operations:
-Password changes
-Usage of the accounts
-Modifications of the rights of the accounts
BtG account passwords are changed when:
-The account is compromised
-The account is tested or used
-Someone with permission to view a half of the BtG password loses permission to access the password
The BtG accounts are tested every 6 months.
Any usage without approval of the process owner of the BtG accounts is reported to CERT-UU as a security incident. This is usually done by UU ITS Security Operations, the application owner or the process owner.
IS.02.006. MFA for Privileged Access
Description
Authentication for access using privileged accounts has multi-factor Authentication. This includes applications, systems, and networks.
Devices cannot be marked as ‘trusted’ for multi-factor authentication for privileged access.
MFA for privileged access with SolisID-based accounts is centrally managed, either through the use of a trusted IdP, or a stepping stone.
Technical specifications
The standards for MFA for privileged access adhere to the technical specifications from IS.9.005 – Multi-Factor Authentication with the following additions:
Privileged access to ‘sensitive’ systems, applications or networks requires at least level 2 MFA. Privileged access to ‘critical’ systems, applications or networks requires level 4 MFA.
The MFA device must be dedicated to privileged access only. In the case of level 2 this means a separate code for non-privileged and privileged access and no option to accept an incoming MFA request. In the case of level 3 and 4, this means one hardware token/YubiKey for non-privileged access and one for privileged access.
Rationale
Privileged access is the most important access. Therefore, we require this access to be extra protected by using MFA.
To prevent access after a theft, devices cannot be marked as trusted.
Centrally managing MFA allows for tighter control and, if needed, the resetting of the MFA.
IS.03.001. Vulnerability Registration
Description
System owners are responsible for documenting all identified vulnerabilities in a dedicated register. The following information must be minimally captured:
- Risk assessment of the identified vulnerability (Low, Medium, High, Critical);
- Date of vulnerability discovery;
- Current status of the risk (New, Resolved, Mitigated, Accepted);
- Individual or entity that has accepted the residual risk;
- Date by which the risk must be re-evaluated.
Vulnerabilities that are not expected to be remediated within 30 days should be recorded as exceptions in the vulnerability register. Should 30 days elapse without the exception being documented, it must be recorded as soon as reasonably possible thereafter.
Resolved vulnerabilities must be retained in the register for a minimum duration of one year.
Technical specifications
Technical details of vulnerabilities are considered ‘sensitive’ on the confidentiality scale. The details should thus be stored and processed in systems that apply all the security controls for ‘sensitive confidentiality’ as described in this SCF.
For systems that are internal to the UU network UU ITS – Security Operations can be contacted to help detect vulnerabilities and create a list of vulnerabilities in systems through their vulnerability management services.
For systems that are external to the UU network, agreements need to be made with external suppliers for actively detecting and remediating vulnerabilities. The UU must be informed when systems are exposed to high risk vulnerabilities for more than a week. The UU is informed, in a timely manner, when patches for these vulnerabilities are implemented.
IS.03.002. Vulnerability Risk Estimation & Resolution
Description
Last updated: 13-11-2023
Vulnerabilities are treated based on the risk-estimate of found vulnerabilities according to the CVSS score of the vulnerability and their the estimate of the risk-context:
| Risk-context UU | Critical | Medium | High | Critical | Critical |
|---|---|---|---|---|---|
| High | Low | Medium | High | Critical | |
| Medium | Low | Medium | Medium | High | |
| Low | Low | Low | Medium | Medium | |
| Low [0-3.9] |
Medium [4-6.9] |
High [7-8.9] |
Critical [9-10] |
||
| CVSS-Score of the vulnerability | |||||
For external suppliers, the risk-context is the highest of the AIC-ratings of the Security Capability Level (where Low = Low, Basic = Medium, Sensitive = High and Critical = Critical).
If CVSS-score is not yet available, a professional estimation is made based on the ease of exploitation, exposure of the vulnerability, observed exploitation internally and externally and the potential impact of the vulnerability.
Vulnerabilities need to be resolved depending on their risk-estimate and the following resolution times:
| Risk-estimate | Maximum resolution time |
|---|---|
| Critical | 5 working days |
| High | 1 month |
| Medium | 3 months |
| Low | Best effort |
Technical specifications
Total number of assets per CVSS level per faculty is reported on a monthly basis also trends of the past 3 months are reported.
IS.03.003. Coordinated Vulnerability Disclosure Policy
Description
The organization has a published Coordinated Vulnerability Disclosure Policy to encourage security researchers and individuals to ethically find and report vulnerabilities.
Technical specifications
UU responsible disclosure:
https://www.uu.nl/organisatie/it/verantwoorde-openbaarmaking (NL, leidend)
https://www.uu.nl/en/node/1599/responsible-disclosure (EN, translation)
For external suppliers the policy should be in accordance with the guidelines of the Dutch National Cyber Security Centre (NCSC): https://english.ncsc.nl/publications/publications/2019/juni/01/coordinated-vulnerability-disclosure-the-guideline..
IS.03.004. Automated Vulnerability Scanning
Description
Network connected IT systems are subjected to automatic vulnerability scanning based at least once per month.
Scanning occurs authenticated where possible.
Technical specifications
Security Operations ITS of the UU will specify, maintain and publish requirements and approved tooling for vulnerability scanning.
System owners can ask for access to administer detected vulnerabilities. All production servers in UU network must be connected to this central scanning solution.
IS.03.005. Automated (Web-)Application Vulnerability Scanning
Description
(Web-)applications are subjected to (web-)vulnerability scanning. Depending on the classification of the application the interval of scanning is:
Basic: At least once every year
Sensitive+: At least once every 6 months
New and updated (web-) applications are scanned for vulnerabilities before going live or with major changes.
Recent scan reports are available.
Technical specifications
Web application scanning is done to find errors in web applications such as those listed in the OWASP top 10.
Dynamic Application Security Testing (DAST) is applied. If a web application is critical in any of the CIA segments, then Static Application Security Testing (SAST) needs to be applied in addition to DAST.
Scanning of applications that have different user privileges is done at multiple authentication levels: public, standard user and privileged user.
Security Operations ITS of the UU has a service for DAST (web) application scanning.
IS.03.006. Penetration Testing
Description
Before go-live of new IT services, and after major updates and changes, a penetration test of the information security needs to be performed by a trusted party. A penetration test takes place at least once every 2 years.
The management summary should contain at least which party performed the test, when the test was performed, what the scope of the test was, the number of vulnerabilities that was found and their associated risks.
Found vulnerabilities must be handled according to IS.3.002.
Rationale
Security Operations ITS (SecOps) has a penetration testing service and should be consulted for all penetration tests of the UU network and systems.
For penetration tests done by suppliers (including cloud suppliers), performed outside of the UU context, SecOps can advise on the required summary of the results and follow up.
IS.03.007. Update Management
Description
Only supported software can be used. End-of-Life or End-of-Support software /hardware is not allowed.
For Sensitive and higher classifications: Additionally, any internally developed software must have a designated data management plan and a software management plan in place before it is deployed. These plans must outline the support responsibilities, maintenance activities, and the expected lifecycle of the software. Internally developed software can only be used if it is fully supported and maintained for its entire expected usage duration by the responsible team within the organization.
Software is tested and installed according to a documented and defined patch cycle.
System owners are required to proactively obtain information relevant to their systems to ensure they remain up-to-date with the latest security patches and updates. System owners must ensure that all updates are assessed for their relevance and impact on their systems and must schedule and apply patches and updates according to the change management process. External services must adhere to the same policy regarding update management (or a stricter one).
Unpatched systems will be treated in accordance with the vulnerability management process.
Technical specifications
InsightVM, our Vulnerability scanning service, can also detect outdated software automatically with high accuracy, when an additional agent is deployed on the target systems. Users can create automated reports to receive a list of systems that are using outdated software.
Make sure the updates are from a trusted source, like the official site of the manufacturer, and be sure the file is not altered in transit, e.g. by verifying the hash or CRC code.
A description of the UU change management process can be found on Sharepoint: link. Or contact the change manager ITS for a hardcopy.
IS.3.002 describes the process for unpatched systems and describes maximum tolerable resolution times.
Note that some older protocols are not allowed anymore. More information on these protocols can be found in Deep dive – SMB, NTLM en LDAP.
https://solisservices.sharepoint.com/sites/10046/ChM/Documenten%20van%20Changemanagement/Forms/AllItems.aspx?viewpath=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FForms%2FAllItems.aspx&id=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FProces%2C+procedures+en+werkinstructies%2FProces+beschrijving+Change+Management_V3.4.pdf&viewid=5d254635-dc8f-4521-ba51-6c8faf4cbd2b&parent=%2Fsites%2F10046%2FChM%2FDocumenten+van+Changemanagement%2FProces%2C+procedures+en+werkinstructies
https://solisservices.sharepoint.com/:w:/s/10824/EVQoo0wrS-1GqFAqED1DhiQB7xrrmMlzBMUhe8MFvN5o6Q
IS.03.008. Emergency Updates
Description
An emergency update is an unscheduled software update released to address critical vulnerabilities, significant bugs or major performance issues that cannot wait for the regular update cycle. A patch that is released on schedule but has a high risk if it is not deployed faster than the regular update cycle is also considered an emergency update.
After the deployment of the emergency update the normal update process is followed post-deployment. Stakeholders are informed, audit trails are created and change management process is followed retroactively.
A procedure for applying emergency updates should be in place.
Technical specifications
System owners continuously monitor for new security advisories, vendor notifications and threat intelligence reports from their suppliers that may contain emergency update information.
When an emergency update needs to be deployed it is first authorized, prepared and deployed on a test environment before applying it to production environments.
A rollback scenario must be ready before emergency updates are applied.
After an emergency update is deployed the systems will be monitored closely to determine any unforeseen impact of the update.
Rationale
Emergency updates close critical vulnerabilities that cannot wait for the normal patch cycle. Rapid deployment prevents exploitation during active threat windows. A controlled but accelerated process—authorization, testing, rollout, rollback readiness—reduces operational risk while still eliminating immediate security exposure. Post-deployment alignment with normal change management keeps governance intact and provides auditability.
External reference
ISO27002: 8.8 Management of technical vulnerabilities 8.19 Installation of software on operational systems 8.9 Configuration management 5.7 Threat intelligenceIS.03.009. Hardening Validation
Description
IT systems have standard configurations that follow recommended hardening guidelines.
Before new systems are taken into production, the systems are tested for adhering to the hardening guidelines.
The standard images are tested for security vulnerabilities during regular vulnerability management process and are updated accordingly.
Technical specifications
Hardening or security guidelines by the supplier are followed. If guidelines of supplier is absent or insufficient, third party guidelines should be used.
OR:
The most recent version of the CIS Benchmarks are taken into account when configuring devices or operating systems. L1 controls are implemented. If a control cannot be implemented because of business reasons, the exclusion and the reason(s) is/are documented.
IS.03.010. Rollback Procedure
Description
Major changes and/or migrations that could have potential impact to the availability of the IT service need to have a rollback procedure and a step-by-step plan for the change documented on forehand and approved by the relevant change boards.
This rollback procedure can be requested.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Changes and migrations to IT systems may have a direct impact on the availability and stability of IT services. When such changes are implemented without adequate preparation or cannot be reverted, there is a risk that disruptions to critical systems may persist or that recovery actions cannot be executed in a timely manner.
By defining a rollback procedure and a documented step-by-step change plan in advance, organisations ensure that they are prepared for unexpected outcomes of changes or migrations. This enables administrators to restore systems to a previously stable configuration if a change introduces service disruptions or unforeseen issues.
Requiring rollback procedures to be documented and approved by the relevant change boards strengthens change governance and ensures that risks to service availability are assessed before implementation. This prevents changes from being executed without a clearly defined recovery strategy.
This measure supports controlled change management, reduces the impact of failed changes, and contributes to the continuity and reliability of IT services.
External reference
ISO/IEC 27001:2022 Annex A – A.8.32 Change management (Primary), A.8.9 Configuration management, A.5.37 Documented operating proceduresIS.04.001. Network Documentation
Description
All network equipment is documented and kept up-to-date with security updates.
Zoning information and access methods for the different zones are documented.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
A well-documented network architecture forms an essential foundation for effective network security management. Without up-to-date documentation of network equipment, network zones, and access methods, it becomes difficult to understand the structure of the network and the security controls that apply to it. This may result in configuration errors, unclear responsibilities, or insufficiently protected network segments.
By systematically documenting network equipment, network zones, and access mechanisms, organisations obtain a clear overview of their network architecture and security segmentation. This enables administrators and security teams to manage changes more effectively, analyse incidents, and assess security risks within the network environment.
Maintaining accurate documentation also supports the management of security updates for network devices and ensures that network components are managed consistently. This allows organisations to determine which systems may be affected by vulnerabilities or configuration changes within network infrastructure.
Keeping network documentation up to date strengthens governance, change management, and auditability. Documenting network architecture and access mechanisms ensures that network security controls are applied consistently and that changes to the network environment can be managed in a controlled manner.
External reference
SO/IEC 27001:2022 Annex A – A.8.20 Network security (Primary), A.8.9 Configuration management, A.5.37 Documented operating proceduresIS.04.002. Networking Hardware
Description
Networking maintains a list of approved hardware components and their required configurations. This equipment and configuration is approved by Security Operations ITS of the UU for use in production.
Networking hardware components are not accessible to unauthorized individuals.
Technical specifications
Switches do not operate in promiscuous mode.
TACACS+ is preferred over RADIUS as a means of authentication.
SNMPv3 Community strings and passwords are managed as part of privileged access management and thus rotated when there have been changes in the roles or employment status of anyone with access to them. The use over SNMPv2 is prohibited.
Anti-spoofing protection is in place, such as IP Source Guard (CISCO), Port Security, DHCP snooping and Dynamic ARP Inspection.
IS.04.003. Network Segmentation
Description
Networks need to be segmented if they have different risk levels. This mitigates the risk of one intrusion spreading to other parts of the network.
Each network segment is separated by a (virtual) firewall.
Technical specifications
Traffic between different segments needs to go via a network firewall with stateful firewalling.
Traffic trying to circumvent these measures must be dropped.
Also see IS.4.011 for systems with critical classification.
IS.04.004. DMZ
Description
The DMZ (demilitarized zone) is the network location for public-facing services.
Only systems in the DMZ can accept communications initiated from outside the network.
The DMZ is separated from the outside world and the internal network with Firewalls.
Only the public facing component of a service can be in the DMZ, data processing and storage must be in separate parts of the network according to the data classification.
Systems within the DMZ treat other DMZ systems as non-trusted.
Inside services verify requests from DMZ hosts to have the right source and authorization.
Technical specifications
Use a stateful firewall between the outside world and the DMZ, and between the DMZ and backend services or storage. Configure the DMZ host to only run services it needs for or in support of the public function. Configure the local and network firewalls to minimize exposure of management functions
Management of a DMZ host has to happen via a bastion host, not directly from the outside world.
Connections from DMZ hosts to the inside need appropriate levels of encryption and authentication with a non-personal privileged account.
IS.04.005. Firewall Rule Management
Description
The network firewall is set up to protect hosts on the network against networkflows that are potentially insecure. The firewall is one part of a layered defense.
The firewall rules are set to default deny traffic and only rules are implemented that allow what is necessary for functionality as described in the architectural design.
All firewall rules are documented with a textual explanation of their purpose and a revision date. Firewall rules are revised on or before their revision dates.
Access to the firewall itself should be appropriately protected, has a safe configuration by default: filtering all traffic and not exposing administrative interfaces.
Firewalls log denied and allowed traffic for the purpose of investigating network problems or security incidents.
Technical specifications
Firewalling is stateful by default: traffic that is in response to or clearly to an already allowed connection is allowed.
IP source routing information is not allowed.
Traffic with the Firewall as destination must be blocked for traffic other than intended administrative tasks.
Traffic with invalid source or destination addresses should must be dropped.
Firewall rules are kept synchronised for IPv4 and IPv6
Broadcast destination addresses aren’t forwarded
Firewall performance should be sized according to SLA goals
Follow best practices in https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf “NIST Guidelines on Firewalls and Firewall Policy”
IS.04.006. DDoS Network Protections
Description
Network of IT services must be hardened against Distributed Denial of Service (DDoS) attacks.
Services are configured to avoid participating in DDoS attacks.
There is a documented procedure in the event of high network load (in the case of for example DDoS attacks).
Technical specifications
The (D)DoS protection of a preferred supplier is used.
No open DNS resolvers, NTP amplification
Blocking of broadcasting requests to internal IP addresses originating outside of the network
Routers with Access Control Lists
Configure BPDU guard against Spanning Tree Attacks
Rate-limiting is applied either consistently or dynamically to substantial and potentially malicious traffic
Load Balancer
TLS offloader
IS.04.007. Secure ISO Layer 2 & 3 Protocols
Description
Secure and up-to-date standards are used for networking protocols.
IPv6 is supported. Firewall rules applicable to IPv4 need to be replicated for IPv6.
Technical specifications
Where WiFi is used, it uses at least WPA2 Enterprise or more modern standards.
In lab environments, appropriate configurations of networking protocols such as NFC, Bluetooth, Zigbee & Modbus are used that meet business and security requirements.
IS.04.008. Network Access Control
Description
Network Access Control is used to determine the level of access users and devices are given to the network. Unidentified users may get access to a guest network.
Access to certain networks requires at least both validated users and validated devices. Device authentication (preferred) or validation of its attributes (less preferred) proves the device is under organisational control and meets required specifications.
Authenticated users with managed devices can be allowed in the internal network after verification of the correct level of operating system, applications and endpoint protection.
Technical specifications
The identity to use for network access, in order of decreasing trust level:
-Machine authentication (certificate verification)
-User authentication (certificate verification, password verification)
-Physical location on the network (which port on the network)
-Machine hardware identity (ethernet mac address)
Additional conditions for access control decisions:
-Patch level of operating systems, relevant applications and endpoint protection system
This decision can be made either based on a lookup of the verified machine identity in the configuration management database or by communication with a trusted agent on the system. Machine identities can only be considered verified based on a trusted certificate.
Trusted machine identities are managed by selected identity providers, through a vetted process. Machine identities are only provisioned on validated, managed devices that meet all requirements.
Base protocol for access control is IEEE 802.1x to establish machine or person identity.
IP addresses are not a reliable means of authentication and should only be used in access control as a last resort
Is.04.009. Network Naming Security
Description
Best practices for Network Naming Security are followed.
UU managed systems belong to one, UU managed, security domain.
DNS records only point to UU managed systems or partners through which we, by means of contractual agreements, have validated the information security and suitability.
Technical specifications
Network naming uses the DNS protocol. DNS implementations follow the accepted Internet RFCs describing the protocol and implementation.
Network naming uses the DNS protocol. DNS implementations follow the accepted Internet RFCs describing the protocol and implementation.
DNS service is monitored for availability and correctness, including DNSSEC validity
DNS implements need-to-know when answering requests, this means:
-DNS servers only allow zone transfers between authorized DNS servers.
-Obsolete records are deleted after an appropriate amount of time.
-Information in network naming which has no functional need is not published. This means DNS HINFO and DNS LOC records or other types that have limited current use but do give out information are removed.
-DNS information with limited scope is only accessible within that scope. This means access control lists are used to limit access to internal information. Make sure restricted and unrestricted clients get a consistent view of DNS information.
DNSSEC is implemented for DNS zones owned by the UU.
Sensitive or higher services must implement DNSSEC and DNS answers should be validated
Domain registrations are protected against unwanted transfers or expiration.
Records pointing to resources outside organizational control are reviewed periodically (at least yearly).
DNS service is monitored for availability and correctness, including DNSSEC validity
DNS implements need-to-know when answering requests, this means:
DNS servers only allow zone transfers between authorized DNS servers.
Obsolete records are deleted after an appropriate amount of time.
Information in network naming which has no functional need is not published. This means DNS HINFO and DNS LOC records or other types that have limited current use but do give out information are removed.
DNS information with limited scope is only accessible within that scope. This means access control lists are used to limit access to internal information. Make sure restricted and unrestricted clients get a consistent view of DNS information.
DNSSEC is implemented for DNS zones owned by the UU.
Sensitive or higher services must implement DNSSEC and DNS answers should be validated
Domain registrations are protected against unwanted transfers or expiration.
Records pointing to resources outside organizational control are reviewed periodically (at least yearly).
IS.04.010. Server Internet Access
Description
Servers do not have direct access to the public internet.
Updates and licensing for production servers go through dedicated and product specific proxy servers for these purposes. Users can access internet, if needed through proxy services such as Citrix.
IS.04.011. Critical Systems in Own Segments
Description
Critical systems reside in their own segment based on business function. Critical systems that form part of different IT services are (logically) separated into their own network segment.
Each network segment is separated by a (virtual) Firewall.
Technical specifications
Traffic between different network segments needs to go via a network firewall with stateful firewalling.
Traffic trying to circumvent these measures must be dropped.
Equipment which is not part of the network infrastructure and has multiple interfaces, must be configured in such manner that routing or forwarding is not possible between interfaces. This is also required for VPN interfaces on a system.
IS.05.001. Clock Synchronisation
Description
Logs contain standardized timestamps that are synchronized to a reference time source and contain an established time zone or the time zone is documented.
Technical specifications
NTP or NT5DS is used to synchronize computer clocks to a central timeserver slaved to a GPS receiver or other source of time traceable to the international UTC time standard.
Log timestamps are in the local time zone (with correct DST handling), or in ISO 8601 notation to allow correlating log entries with other logs
IS.05.002. Remote Logging
Description
Logs for the audit trail need to be stored on a logging server that is not the source that generated the logs and is a dedicated server for managing logs. The IT service ideally supports logging to an UU managed central logging server.
The UU can ask for relevant audit logs for incident resolution. This can also take the form of a permanent, near-live, datastream to the centralized security monitoring solution managed by the UU. This is only required when the UU requests it, but can be requested as a feature at any time.
A retention period for logs is defined based on abuse cases and relevant business and legal requirements. It is recommended to work with rotating logs.
Technical specifications
Logs contain at least:
• A timestamp
• User ID
• The originating system of the log
• The activity performed
Logging data retention is 6 months for security incident handling. Logging retention for the purpose of normal operational activities is 2 months maximum.
IS.05.003. Mutation and Data Access Logs
Description
Applications log access (attempts) to data.
Applications log mutations of system configurations and sensitive data. Original values are recommended but not necessitated to be stored.
Technical specifications
Mutation and data access logs adhere to all logging rules as defined in IS.5.002.
IS.05.004. Authentication Attempts
Description
Authentication attempts are logged including originating IP and attempted user. Passwords are not logged.
Technical specifications
AD Security audit log central policy enabled.
IS.05.005. Log Protection
Description
Stored logs are appropriately protected from deletion, editing and unauthorized reading and writing.
Technical specifications
Logs are ‘read-only’ by default.
Permissions on log files can only be changed by privileged users.
The privileged users of the log file server(s) cannot be the same users as the system the logs are originally from.
On linux-systems log files have the append-only flag attribute. Conse33quently, to limit removal of the append-only flag, the capability CAP_LINUX_IMMUTABLE must not be set on the log file. A log rotate account is allowed to have the capability. Access to the log rotate account should be limited to privileged users only.
On windows-systems the default protections of the windows event log format should be in place. This means: Have windows event logging turned on and have it log relevant events. The windows event log does not allow for deleting of the logs without an event being written that states it was deleted. Limit access to this ability to administrator level accounts only.
IS.05.006. Logging of Log Access
Description
Access to logs is in itself logged. These logs are stored separately and permissions to these logs are least privilege and separated.
Technical specifications
At a minimum the following information is logged:
• What user accessed a log
• When was the log accessed
• From what device (MAC) was the log accessed
• What IP was the log accessed from
Users with privileged access to logs cannot have privileged access to the logs of log access. Privileged access is editing, creating and deleting of the logs. Reading the logs is not considered privileged access, but should adhere to least privilege principles regardless.
Logging of log access retention is 6 months.
IS.05.007. Logging of Network Access
Description
Access to the UU network is logged and every action can be resolved to a user.
A purpose of logging network access is to assist in finding a machine/person identity when resolving an incident where a network identity (IP address) and a timestamp is available.
Technical specifications
The following elements should be logged:
Network authentication (802.1x, wifi or other logging for identification, authentication and authorization used to access the network)
Translation between network identity (IP address) and mac address (ARP for IPv4, NDP for IPv6)
Location on the network (physical ports for wired network, used access points for wireless)
Network access logging has timestamps which can be used in correlating events. This means clocks are synchronized and the timezone of the logging is clear.
The logging is retained for the purpose of network management for 1 month and for the purpose of security monitoring for 6 months.
IS.06.001. Exit Strategy
Description
A documented plan exists for how to transition away from the suppliers needed for the IT service both at short notice and more gradual, to avoid vendor lock-in, when contracted services or products change to no longer suit needs or when in emergency situations the service does not offer sufficient capabilities
The exit strategy is revised every 3 years.
IS.06.002. Emergency Power
Description
Emergency power to IT equipment is available or a hot-site connected to a separate power source is available.
Emergency power or the hot-site connection is tested once per 6 months.
Technical specifications
Dual power supplies (A+B feed). N+1 redundancy: system will work with 1 power supply missing.
IS.06.003. Internet Connectivity Redundancy
Description
The connection to the internet is redundant for all necessary connected equipment part of the service. There are no Single-Point of Failures (SPOFs) on any layer.
Providers can demonstrate this redundancy, and show that it is tested at least once a year.
Technical specifications
Separate fiber paths, multiple routers, fas
IS.06.004. Throttling
Description
A procedure is in place to throttle traffic from non-critical sources, to ensure continued minimal essential functioning of the service.
Technical specifications
Integrate QoS in network design.
IS.06.005. Data Centre Uptime
Description
Datacentres used in IT service providing have measures in place according to Uptime Institute Tier II (or equivalent) or higher.
IS.06.006. Data Centre Uptime Guarantees
Description
Datacentres used in IT service providing have measures in place according to Uptime Institute Tier III (or equivalent) or higher.
IS.07.001. Risk Monitoring
Description
Event data is aggregated from multiple sources.
Accepted organizational risks are monitored through defined abuse cases.
Personnel security and awareness is monitored and periodically tested. This information can only be used for improving security and is never reported on a per-user identifiable level. Relevant privacy and security measures are taken to handle this information.
IS.07.002. Egress & Flow Monitoring
Description
A list of relevant known IOCs is maintained and shared among industry peers.
A list of known malicious networking addresses is maintained for egress filtering.
Network flow monitoring is applied for detecting intrusions, denial of service, unauthorized actions and other relevant security purposes.
IS.07.003. Abuse Case Identification and Monitoring
Description
At least once every 2 years, potential abuse cases for the IT service are identified and revised.
Relevant monitoring for abuse cases will be implemented and the service owner sets the thresholds for possible alerts and organizes the follow-up.
Event data form multiple sources needs to be considered and correlated for the abuse cases.
Technical specifications
Magma framework
IS.07.004. Password Monitoring
Description
There is security monitoring on organizational credentials appearing in (publicized) data-breaches.
If there are indications of compromise of passwords or risks the credentials of individuals are compromised, passwords will be forcibly changed and the users informed.
Technical specifications
Implement logging and monitoring mechanisms to track events, such as failed login attempts and account lockouts. This shows suspicious password-related activities and gives indication of an account or password breach.
Use a Password Protection system that can check accounts or password hashes against breach websites. Examples are haveibeenpowned.com or dehashed.com.
Have procedures in place, or automate, the changing of passwords when a password has been breached.
At the UU IAM, CERT-UU and the ITS Servicedesk fill these tasks. Suppliers will need to implement this, for accounts they manage, themselves.
IS.07.005. Intrusion Detection System
Description
Intrusion Detection Systems are in place to proactively detect active attacks and attempts against critical IT services.
Attacks against the IDS are used to define new and improve existing abuse-cases and monitoring.
Technical specifications
Honeypots or Honey-accounts are used: Honeypot systems are systems that outwardly appear as genuine versions of the critical applications, but with vulnerabilities. These systems contain no sensitive data and are monitored closely for attacks, to identify ongoing persistent threats in the network.
IS.07.006. Red Teaming
Description
Red teaming is used to identify weaknesses in the security posture of the organization at least every 3 years.
Attack vectors and lessons learned are acted upon to improve the security posture of the UU (or supplier).
The CISO office and the DPO will be consulted prior to all red teaming activities.
Technical specifications
Red teaming of UU systems is done through UU ITS – Security Operations as part of the vulnerability management service. Systems with the ‘critical’ classification need to be registered at the CISO office to be included in the scope of the red teaming.
Red teaming does not need to be initiated or checked by the system owner. Red team exercises are not communicated past a select group, to keep responses as realistic as possible.
The mandate of the CIO of the UU needs to sign off on all internal red teaming exercises.
If additional red teaming on UU systems is wanted, then UU ITS – Security Operations will help to set this up.
If this security control is applied to a supplier, then the supplier must be able to show a recent red team management summary done in the last 3 years. The red team exercise should have an appropriate scope to the service the supplier delivers. The third party having done the red team exercise should be a company both the UU and the supplier agree is competent and independent.
IS.07.007. Network Intrusion Prevention Systems
Description
A baseline for normal network and application packet traffic is established around critical IT services.
Network Intrusion Prevention Systems are used to dynamically detect deviations from the baseline.
IS.07.008. Contact With Industry Monitoring
Description
Industry contacts with other Security Operations ITS and CSIRTs need to be maintained and relevant information regarding threat actors and vectors shared.
IS.07.009. Certificate Monitoring
Description
There is monitoring for CT-logs for certificates that seem to be issued to the organization.
IS.07.010. Spoofing and Fraud Monitoring
Description
There is monitoring for online presences that claim to be organizational but are in no way affiliated, including domains and email addresses.
Malicious actors will be blocked.
Hosting parties are asked to cease supporting the malicious activities.
Relevant authorities are engaged where appropriate and legal steps taken.
Technical specifications
CERT-UU
IS.07.011. Advanced Persistent Threat Monitoring
Description
Attack vectors known to be used by Advanced Persistent Threats (APTs) are actively monitored. When the threat of APTs is active, appropriate personnel will get informed of the threat and what they can do to reduce the risks.
Technical specifications
Cooperation with SURFCERT
IS.08.001. Local Privileged Accounts
Description
Regular end-users do not have the ability to modify systems privileged access to endpoints, including the ability to modify organisationally managed system settings, including making changes to environment variables, directly read or modify the registry, modify files in system directories or install programs.
Approved business applications are deployed through a centrally managed solution.
User workstations have protections to prevent them from leaving the organizational domain.
Privileged setting and features cannot be controlled using a non-privileged account.
Only users that have a demonstrable need for a local privileged account to perform their work activities can have access to a local privileged account. This access adheres to the privileged access controls, including just-in-time and is just-enough admin.
IS.08.002. Endpoint Updates
Description
All endpoints (including desktops, laptops, mobile devices, and servers) must be kept up to date with the latest software, firmware, and operating system updates. This includes security patches, bug fixes, and relevant feature enhancements.
A system is considered out of date if it has not applied the most recent security updates within 30 days of the release of the patches.
Administrators need to stay aware of patches for their relevant software, firmware and operating systems.
All software, firmware and operating systems in use must be supported by the vendors. If software is end of life it needs to be it needs to be dealt with according to IS.15.007.
Important security updates must be able to be deployed to endpoint devices within shorter time frames depending on the risks.
Endpoints that are lagging in security updates should not get access to sensitive or critical organizational data.
Technical specifications
Users are allowed to postpone non-important security updates for a maximum of seven days, after which the updates should be forcibly installed.
An important security update is defined as one that mitigates a vulnerability posing a high risk due to factors such as criticality and urgency. It is also considered important if vulnerability is actively being exploited. For more information, see IS.3.008. A high risk may be indicated by a high CVSS score, but it can also result from a combination of lower-scoring vulnerabilities that can be chained together.
The system- and dataowners are responsible for tracking vulnerabilities. Security Operations tracks vulnerabilities on a best-effort basis.
Updates must be tested in an acceptance environment before being deployed to production. This step may be bypassed if the update is classified as an important security update.
The deployment software must be able to rollback any patch in case of failure or unexpected impact.
Endpoint update status must be monitored by administrators.
Updates for firmware and operating systems must be managed via centrally administered deployment software.
Rationale
Endpoint Updates ensures that every endpoint—laptops, desktops, servers, mobile devices—remains protected against known vulnerabilities by enforcing timely installation of security patches, firmware updates, and supported software versions. Systems that fall behind expose the entire environment to compromise, particularly when critical or actively exploited vulnerabilities are left unpatched.
The control imposes strict timelines for important security updates, requires administrators to track vendor releases, and mandates removal or replacement of unsupported software. Testing and controlled deployment reduce operational risk, while rollback capability limits impact when updates cause issues. Blocking outdated endpoints from accessing sensitive data prevents lateral movement and targeted exploitation.
This maintains baseline security hygiene across the environment and prevents endpoints from becoming the weakest link in the organization’s threat surface.
External reference
ISO27002: 8.8 Management of technical vulnerabilities 8.19 Installation of software on operational systems 8.9 Configuration managementIS.08.003. BIOS protection
Description
BIOS access on organizationally managed hardware is password protected.
BIOS passwords are considered and treated as privileged access.
BIOS passwords need to be managed.
Boot from external sources disabled.
IS.08.004. Data Storage Encryption
Description
Data at rest must be stored encrypted
Technical specifications
Full disk encryption is preferred, using trusted key management and trusted boot to a managed operating system to allow access.
Encryption of data at rest, including full disk encryption, uses Advanced Encryption Standard (AES) with at least 128 bit key length. Masterkeys should be fully random and unlocked with password-based key derive functions.
Managed devices should have a managed encryption unlock key. On access to these managed encryption keys, a new key should be generated and the unlock key replaced (for example Microsoft Bitlocker Administration and Monitoring).
Endpoints should support Secure Boot and storage of keys in a Trusted Platform Module (TPM).
IS.08.005. Scripts and Executables
Description
Last updated: 30-7-2020
Unless necessary for executing job responsibilities, user endpoints will by default not allow the execution of scripts and executables.
If the function necessitates this access, it will be documented and requested by the supervisor.
Technical specification:
Office Macro’s and Powershell are disabled by default.
It’s optionally granted when a valid motivation is provided.
IS.08.006. Malware Protection
Description
Anti-malware tooling is present on endpoints.
Anti-malware software needs to be mature and effective. Tooling and malware definitions are kept up-to-date.
Peripheral devices are not allowed to auto-run content.
Technical specifications
The anti-malware tooling needs to have a minimum set of features:
A high malware detection rate and both signature-based and behaviour-based detection of malware and a sandbox feature in which it will examine files for malware. This feature is usually enterprise specific and not for consumers, but should still be available when working from home and not in the UU network.
Run on-access scans on any files accessed, including directly attached storage and files accessed through the network.
On Windows the tool needs to hook with AMSI to detect in-memory malware.
Anti-malware tooling for Linux and Unix variants is less robust than for Windows and Mac. To limit the damage malware can do anti-malware tooling is still required, but behavioural detection and sandboxing is expected to be less complete. Because of this on ‘basic’ and ‘sensitive’ systems a mandatory access control (MAC) system needs to be implemented that limits permissions of processes, files and users on a kernel level. The MAC needs to be set in a prevention/enforcement mode, not just detection. AppArmor in its default configuration is an example of one such system. For ‘critical’ systems the system needs to be more granular and configured with rules that are specific for the system/application. To ensure this an example would be a specifically configured SELinux or a manually configured and hardened AppArmor installation.
A list of pre-approved anti-malware tooling is kept by UU Security Operations ITS.
IS.08.007. Memory Protection
Description
Endpoints need to have appropriate protections to prevent attacks on memory.
Technical specifications
Endpoint OS needs to have Address Space Layout Randomization (ASLR) enabled.
Endpoint OS needs to use executable-space protection, preferably through hardware NX-bits. DEP is enabled for Windows.
IS.08.008. Screen Lock
Description
After a period of inactivity, on a managed workstation, the session/screen is locked and the user is prompted for authentication again.
Users must be trained to lock their screen when they step away from the workplace.
Technical specifications
A screen lock policy must be centrally managed. The screen lock policy must be enforced on all managed workstations. The policy should automatically lock the system after 15 minutes.
IS.08.009. Data in Managed Environments
Description
Sensitive data only resides in organizationally managed environments. This can include managed devices or managed containers on unmanaged devices.
Before sensitive data leaves the organization, official relations including agreements with the receiving party about data storage and handling exist.
Technical specifications
Apply CASB solution to monitor leakage of sensitive data to depreciated services. Inform users about the officially supported services e.g. https://tools.uu.nl/tooladvisor/. Discourage use of shadow IT.
IS.08.010. Remote Wipe of Organizational Data
Description
Organizational data can be deleted from devices remotely.
Encrypted data to which the key is unavailable complies to this standard.
Technical specifications
Deletion of data is on par with NIST Guidelines for Media Sanitization for the level of ‘Clear’ or higher: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final.
Voorbeeld: https://www.umsystem.edu/ums/is/infosec/data-disposal
IS.08.011. Public Workspace Security
Description
Shared workspace endpoints are physically protected from tampering with or removing the hardware.
Public workspace are reimaged daily and do not have autologon.
Browsers on public workspaces delete all cookies and session information when the browser is closed.
IS.08.012. End-Point Backups
Description
Data is not primarily stored on endpoints but in environments with appropriate capability levels.
IS.08.013. Host-Based Firewall
Description
On managed endpoints, the local firewall policies are maintained, reviewed and enforced based on business and security needs.
On unmanaged endpoints the host-based firewall should adhere to least privilege principles.
Technical specifications
ost-based firewalls should be configured to prevent unwanted traffic between endpoints, and to protect the endpoint if exposed to an untrusted network, such as public wifi.
Management traffic and remote login should only be accepted from approved hosts and networks
On systems classified as Sensitive or higher, the risks of administrator lock-out due to (firewall) configuration errors should be assessed and managed.
Both IPv4 and IPv6 and common transport protocols (TCP, UDP) should be supported. If one of these protocols is (partly) unimplemented, the resulting behaviour should be well-known.
Modern implementations, such as application-specific rules and dynamic blocking of risky domains and other known-malicious traffic, are preferred over traditional (static) solutions.
IS.09.001. Authentication Through Trusted Identity Provider
Description
End-user authentication for applications takes place through a trusted Identity Provider (IdP).
The organisation has a defined relationship with individuals that have been given access, either directly or through contractual agreements with third parties.
Only production environments can be linked to production IdPs.
Technical specifications
Authentication services work on a basis of pre-established trust relations between the service requesting authentication and the identity provider (IdP) handling the request. This process uses a combination of encrypted/signed transfer of authentication material, authorization tokens and user information.
The identity provider maintains centrally managed identities for the organization and shares information about these identities with service providers (SP) when needed for the operation of those services. SPs need to use a IdP that is trusted by the UU to authenticate users.
Authentication services by the IdP are based on the SAML or Oauth 2.0 protocol (direct or through a trusted broker like SURFconext).
System authentication for operating system logins is supported through secure authentication protocols as supported by operating system vendors, using established trust relations between systems and authentication services.
IS.09.002. Password complexity & rotation
Description
Last updated: 29-10-2021
Systems that allow setting passwords enforce that passwords satisfy minimum complexity requirements.
Rate-limiting is enforced for failed password entries.
From the data classification policy an account name has a classification of ‘basic’ while a password has a classification of ‘critical’. A hashed password has a classification of ‘sensitive’. These classifications are on the confidentiality axis.
During password creation, an indicator of password complexity is reported to the user. Easy passwords are prohibited. If initial passwords or reset passwords are assigned by the system or by operators, they need to be changed by the user upon first login.
Passwords to personal accounts are only chosen by the account owner. One-time passwords are exempt.
Every account has a traceable owner that is responsible for password maintenance on the account.
Technical specification:
Technical specifications
Only one of the password-policy options below applies to any one account. When in doubt, the stricter policy is chosen. The options are listed from least to most strict.
Chosen passwords must be checked against, a regularly updated, breached passwords list. If the chosen password appears on the list, the password is not allowed to be chosen.
The key space for all passwords is UTF-8. This needs to be supported anywhere a password can be submitted.
A new password cannot be the same as a password that has been used up to 20 times before.
Complexity requirements
Passwords must contain characters from at least three of the following five categories:
- Uppercase characters
- Lowercase characters
- Numerical characters
- Non-alphanumerical characters
- Unicode characters categorized as alphabetic characters but that are not uppercase or lowercase
The length and lifespan of passwords have different requirements based on the type of account:
- Non-privileged personal accounts (End-user accounts)
- Length: Min. 10, max. 127
- Lifespan: Expires every 12 months
- Non-privileged non-personal accounts (Functional accounts)
- Length: Min. 12, max. 127
- Lifespan: Expires every 2 years
- The reason the lifespan is lower than ‘privileged non-personal accounts’ lifespan is that functional account passwords are used by humans regularly and more prone to being re-used and leaked.
- Privileged-user accounts
- Length: Min. 15, max. 127
- Lifespan: Expires every 3 months
- If saved anywhere, then it requires a password vault with MFA
- Privileged non-personal accounts
- Length: Min. 20, max. 127
- Lifespan: Expires every 5 years
Must be saved and managed in a password vault with MFA. Examples: Service accounts or database accounts.
Sources
• https://docs.microsoft.com/en-us/windows/win32/secmgmt/strong-password-enforcement-and-passfilt-dll
IS.09.003. PIN and biometrics
Description
PIN codes are a subset of passwords that usually have limitations to the complexity. Usage of PIN codes in place of passwords is only permitted in a one-to-one relation to physical access (to either hardware or locations). A PIN code is hardware specific, and where possible also user specific.
Biometrics can be used in place of a PIN code if processed on-device and can only be offered as an optional usability feature, meaning a PIN code must be set. Biometric authentication is also subject to rate limiting, and needs to adhere to the guidelines set in according to NIST Special Publication 800-63 section 5.2.3: https://pages.nist.gov/800-63-3/sp800-63-3.html#sec5. There is no central processing of biometric information and the use is always optional.
Technical specifications
The UU password policy is applicable to PIN codes with the following exceptions:
• A PIN code must consist of at least 5 characters
• A PIN code is allowed to consist of only numerical characters
• The limitation that passwords cannot appear on leaked-password lists does not apply to PIN codes
• PIN codes do not need to be rotated periodically
• The password history restriction does not apply to PIN codes
• Rate limiting for PIN codes must be set at 20 consecutive attempts before lockout, or incremental lockout of the hardware device where the time between allowed attempts must be at least 1 minute and increase exponentially after every 5 unsuccessful attempts
IS.09.004. Password Visibility
Description
Passwords must not be visible during entry (other than at creation, when prompted by the user).
Passwords are not visible to anyone (including administrators), meaning they need to be hashed (using a unique salt per user) according to https://www.nist.gov/publications/secure-hash-standard or a superseding standard.
If passwords/secrets are stored, they must be stored in an appropriate password vault service.
Technical specifications
Unknown usernames are not logged, as these may be actually passwords.
IS.09.005. Multi-Factor Authentication
Description
Users need to use a second factor to authenticate before accessing sensitive data or functionality.
Users are allowed to mark devices as trusted, not requiring MFA on that specific device for a period of a maximum of 30 days for access, if the device meets all requirements for a second factor (such as being personal and meeting all hardware requirements).
Users can mark a maximum of 5 devices as trusted. Authenticated users can access an overview of devices they have marked as trusted and be able to remove the trusted status of a device.
Only ‘what you know’ and ‘what you have’ are considered factors for MFA.
Multi-layer authentication, twice the same authentication factor, is not MFA. Two-factor authentication is only two-factor when both steps are different factors.
Biometrics are not used as factors, but can be used as a usability feature in place of a PIN.
MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.
MFA implementations confirm to at least MFA level 2 as specified.
● No distinction is made in location when it comes to MFA. There is therefore no difference between an internal- and an external network for MFA.
Technical specifications
MFA can be set by users and can only be turned off by using MFA, using a previously generated recovery-token, or by determining the identity of the user by a IdP owner mandated admin.
Rate limiting needs to be enforced for failed authentication attempts.
Within MFA there are a number of levels of assurance when it comes to authentication. The higher the level, the more certain the user’s identity. Depending on the data classification, a specific level of MFA may be required. For any level, implementing a higher level is also acceptable. These levels are defined as follows for the UU:
MFA level 1: Out-of band-unencrypted
Short Message Service (SMS) and e-mail based technology. Sending a SMS or e-mail with a code to be input to authenticate.
MFA level 2: Out-of-band encrypted
A software token-based technology. This is software that resides on a device that can generate a code (token) in response to a challenge from the identity provider (IdP). This includes implementations that send a signal from the device to the IdP.
Authenticators must validate to Authenticator Assurance Level 2, according to NIST Special Publication 800-63 section 4.2
MFA level 3: Out-of-band hardware encrypted
A hardware token-based technology. A hardened, separate, device whose sole purpose is to generate a code in response to a challenge from the IdP. This includes implementations that send a signal from the device to the service provider.
MFA level 4: U2F
Universal 2nd factor (U2F) based technology. Based on USB and NFC standards. The IdP challenge is not input by a person, but offered directly through a hardware device. The UU requires implementations that meet the U2F standard of the FIDO Alliance.
At level 4, only a physical visit to the IdP administrators is accepted to reset MFA. It is allowed to use U2F technology at lower levels, whereby the weaker identification requirement applies. However, as soon as U2F is used for level 4, this stricter measure applies.
Users are allowed to mark devices as trusted, not requiring MFA on that specific device for a maximum period of 30 days.
Sources:
U2F standard: https://fidoalliance.org/specs/fido-u2f-v1.0-rd-20140209/fido-u2f-overview-v1.0-rd-20140209.pdf
NIST special publication 800-63: https://pages.nist.gov/800-63-3/sp800-63-3.html
IS.09.006. Re-authentication for Critical Functions
Description
Users need to use a second factor to authenticate before accessing sensitive data or functionality.
Only ‘what you know’ and ‘what you have’ are considered factors for MFA.
Multi-layer authentication, twice the same authentication factor, is not MFA. Two-factor authentication is only two-factor when both steps are different factors.
Biometrics are not used as factors but can be used as a usability feature in place of a PIN.
MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.
MFA implementations confirm to at least MFA level 2 as specified.
No distinction is made in location when it comes to MFA. There is therefore no difference between an internal- and an external network for MFA.
Technical specifications
Examples of extra sensitive or critical functions include: changing grades, changing bank account numbers for payments in excess of a certain amount, exporting entire datasets with highly sensitive information or deleting entire databases.
IS.09.007. Session Timeout
Description
After a period of inactivity in an application, a user session should be locked or terminated and require re-authentication.
The duration of inactivity required to force a re-authentication event is determined by the maximum classification of the actions and data to which the user has access. If this is not clear or possible, the classification of the application itself will be used.
In applications with a security capability of critical closing the browser must invalidate the session on the application.
Technical specifications
For non-privileged sessions: The session is locked or terminated after it times out. The user only needs to re-authenticate to regain access to the session or start a new one.
Depending on the highest of the CIA-levels of the Security Capability Level of the IT service the maximum idle time within the session is as follows:
Basic: 1 day
Sensitive: 2 hours
Critical: 60 minutes
Additionally, on sensitive and critical levels sessions should be closed when the browser or application is closed.
For privileged sessions: Sessions need to be tracked on the server side of the application as well. The server must also invalidate the session when it expires.
IS.09.008. Forced Session Termination
Description
Administrators are able to terminate user sessions on applications in the event of compromised accounts or the immediate termination of individuals. This is preferably done through the application.
A procedure is communicated to the system administrators for executing the emergency session termination. Within 30 minutes of starting the procedure, the user’s session must be terminated. This includes cases where the supplier has to manually terminate a session. This procedure must be supported throughout opening hours (09:00 – 17:00 CEST 5-days a week).
IS.09.009. Unique Identities
Description
Personal accounts belong to one specific natural person, but a natural person can have more than one account. Personal account ownership is never transferred or re-issued. This includes e-mail addresses.
After individuals have left the organization, their legal & natural identities are kept for a predefined period of time, based on business and legal requirements.
Digital access can always be traced to a unique individual.
Appropriate measures are taken to ascertain the identity of a natural person.
IS.09.010. Review of Account Activity
Description
Trusted identity providers (IdP) must have a view for users to review their account activity that shows their latest login activity including when, from which location and which device they logged in. Users can report suspicious behaviour from this portal and are prompted to change login credentials when abuse is suspected.
IS.09.011. Session and Identity Correlation
Description
Protections are in place to detect and prevent unauthorized user activity based on context and behaviour.
Technical specifications
Apply contextual and behavioural authentication.
IS.09.012. Secure Authentication Systems
Description
Security best practices from suppliers of authentication systems are followed and implemented.
Technical specifications
Where used, Windows Active Directories (AD) need to be implemented and maintained according to the Microsoft security recommendations implementing a 3-tiered model and separate Privileged Access Workstations: https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access
IS.09.013. Access Control
Description
Access Control is used to determine the level of access users and devices are given to UU services and resources. Access to these services requires both validated users and validated devices. Device authentication (preferred) or validation of its attributes (less preferred) ensures that the device is under organizational control and meets required specifications. Validated users with unvalidated devices may get access to a guest network or limited access to specific cloud services.
To enhance security and ensure appropriate access levels, users and devices are categorized as follows, with each category having different levels of access to our services and resources based on the compliance status of the device:
-Employees and students using centrally managed workstations.
-Employees and students using decentrally managed workstations.
-Individuals (employees, students, and guests) using ‘Bring Your Own Device’ (BYOD) devices.
-Individuals (employees, students, and guests) using BYOD devices that have been registered and actively monitored on OS version, patch level, AV status, and other specifications.
IS.10.001. Physical Access Limitations
Description
Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 .
Technical specifications
Locations on UU campus housing IT infrastructure used in supporting the service need to be identified to FSC Security and treated according to Physical Security classification level 5. Restricted Area or higher.
IS.10.002. Advanced Physical Access Protection
Description
Access to IT systems is limited to authorized personnel according to the NIST Special Publication 800-53: https://nvd.nist.gov/800-53/Rev4/control/PE-3 including the control enhancements.
Technical specifications
Locations on UU campus housing IT infrastructure used in supporting the service need to be identified to FSC Security and treated according to Physical Security classification level 6. Secure Area or higher.
IS.10.003. Procedures Working in Secure Areas
Description
Procedures for working in secure areas are in place and adherence monitored. The procedures include at a minimum rules regarding
• how and when access can be obtained by whom
• work should be supervised or checked
• no recordings can be made in secure areas
• how guests and contractors can perform their work activities
• rules regarding consumption of food
• emergency protocols and how any out-of-ordinary situations can be reported
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Secure physical areas, such as data centres or other critical infrastructure locations, contain systems and information that are essential for the continuity and security of IT services. When activities within such areas are not governed by clearly defined procedures, there is a risk that unauthorised actions may occur or that employees and third parties may inadvertently bypass security controls.
By establishing formal procedures for working within secure areas, organisations define the conditions under which access may be granted, how work activities must be performed, and how supervision and monitoring are applied. This ensures that both employees and external parties understand the behavioural rules and security requirements that apply within these environments.
Clear rules regarding supervision, recording restrictions, visitor handling and emergency procedures reduce the risk of data leakage, sabotage, unauthorised access or accidental disruption of critical systems. As a result, the integrity and availability of systems located within secure areas are better protected.
Monitoring adherence to these procedures strengthens governance and physical security management. By regulating and supervising activities within secure areas, the organisation can demonstrate that physical security controls are consistently applied and that deviations are identified and addressed in a timely manner.
External reference
ISO/IEC 27001:2022 Annex A – A.7.2 Physical entry controls (Primary) A.7.3 Securing offices, rooms and facilities (Primary) A.7.4 Physical security monitoring A.5.37 Documented operating proceduresDescription
Cables of supporting IT services run out of reach and sight. Inside buildings or outside underground.
Power cables and data cables run separately to avoid interference.
A mechanism for detection of tampering with cabling should be in place. Any tampering with cabling is treated as a security incident.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Cabling forms a critical component of the physical infrastructure supporting IT systems and network services. When cables are easily accessible or visible, there is an increased risk of physical damage, interception, or manipulation. Such activities may lead to service disruption, data leakage, or unauthorised access to network traffic.
By routing cables out of reach and sight or installing them underground, organisations reduce the likelihood of physical tampering or interference. Separating power cables from data cables further helps minimise electromagnetic interference and contributes to the reliability and stability of IT systems.
Implementing mechanisms to detect cable tampering enables organisations to identify suspicious activities or sabotage attempts at an early stage. This allows timely intervention and ensures that appropriate incident response measures can be initiated.
By classifying cable tampering as a security incident, organisations ensure that such events are addressed through formal incident management processes. This strengthens the protection of physical infrastructure while improving governance and traceability of security-related events.
External reference
ISO/IEC 27001:2022 Annex A – A.7.12 Cabling security (Primary) A.7.10 Supporting utilities A.7.4 Physical security monitoring A.5.24 Information security incident management planning and preparationIS.10.005. Inspection of Physical State of Equipment
Description
Equipment needs to be maintained according to the supplier suggested maintenance guidelines and schedules.
There is a maintenance schedule for each piece of equipment.
There is a registration of known physical deficiencies and performed maintenance work on hardware.
Repaired and/or serviced equipment is inspected before being put into production again.
IS.10.006. Auditing of Access to Areas
Description
Access to Secure areas is monitored and audited. This includes at least (sample-based) checks on audit logs of card readers and reviewing camera footage.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Secure physical areas often contain critical IT infrastructure such as servers, network equipment, or storage media holding sensitive information. If access to such areas is not actively monitored and reviewed, there is a risk that unauthorised access may go undetected or that misuse of authorised access privileges is not identified in a timely manner.
By monitoring access activities and reviewing audit logs from physical access control systems, organisations can determine who accessed secure areas and when such access occurred. Periodic verification of these records enables the detection of anomalies, such as unusual access patterns or attempts at unauthorised entry.
Combining access logs with camera footage improves the reliability of monitoring and investigation processes, as physical presence can be verified and incidents can be analysed more effectively. This reduces the likelihood that security incidents or violations of access policies remain unnoticed.
Systematic monitoring and auditing of physical access strengthens the effectiveness of physical security controls and enables organisations to demonstrate that access to critical areas is controlled, traceable, and subject to oversight.
External reference
ISO/IEC 27001:2022 Annex A – A.7.2 Physical entry controls (Primary) A.7.4 Physical security monitoring (Primary) A.8.15 Logging A.5.24 Information security incident management planning and preparationIS.11.001. Recovery Time Objective and Recovery Point Objective
Description
For the IT service the Recovery Time Objective (RTO) is defined and communicated. The RTO is the maximum amount of time the service can be unavailable before significant impact is incurred.
The Recovery Point Objective (RPO) is defined and communicated. The RPO is the maximum amount of historical data that can be lost before significant impact is incurred.
For the IT service, the availability and backup measures safeguard that the RTO and RPO are protected by default.
The RTO and RPO for the service are actualized annually.
Technical specifications
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) values for IT services are defined and maintained as part of the Disaster Recovery Plan (DRP).
The Disaster Recovery Plan describes recovery procedures, backup strategies, failover mechanisms and recovery priorities to ensure that the defined RTO and RPO can be achieved during service disruptions.
Rationale
Defining Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) is essential for managing the impact of disruptions to IT services. Without clearly defined recovery targets, organisations may struggle to prioritise incident response, recovery activities, and investments in availability measures.
By explicitly defining how quickly a service must be restored and how much data loss is acceptable, organisations can align recovery strategies and backup measures with business risks and the criticality of the respective service.
RTO and RPO values also form a key foundation for designing disaster recovery measures, including redundant infrastructure, failover mechanisms, and backup strategies. This ensures that recovery capabilities are aligned with the availability requirements of the organisation.
Periodic review and update of these objectives ensure that recovery strategies remain aligned with evolving business processes, technological changes, and risk profiles.
External reference
ISO/IEC 27001:2022 Annex A – A.5.30 ICT readiness for business continuity (Primary) A.8.13 Information backup A.5.29 Information security during disruptionIS.11.002. Testing of Back-Ups
Description
Restores of backups are tested at least annually and the results of the test are documented.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Backups represent a critical security control for restoring systems and data following incidents such as system failures, cyberattacks, or human error. If backups are not periodically tested, there is a risk that recovery procedures may not function as expected or that backup data may be corrupted, incomplete, or unusable.
By conducting regular restore tests, organisations can verify that they are capable of recovering systems and data when required. This helps identify technical issues, configuration errors, or incomplete backup processes before an actual incident occurs.
Documenting the results of restore tests provides evidence that backup mechanisms are effective and enables organisations to track and address improvement areas. This contributes to the continuous improvement of recovery procedures.
Performing and documenting backup restoration tests ensures that backup controls are not only implemented but are also operationally effective during incidents or disruptions.
External reference
ISO/IEC 27001:2022 Annex A – A.8.13 Information backup (Primary) A.5.30 ICT readiness for business continuity A.5.37 Documented operating proceduresIS.11.003. Offline Backup
Description
Data critical to the operation of the IT service is periodically stored on offline backups.
Offline backups are kept in secure locations and there are procedures in place for restoring and (re-)moving them.
Offline backups are kept geographically separated from the IT source of the backup.
All data necessary to continue operation of a service in case of an incident, are in accordance with the agreed recovery time objective (RTO) and the recovery point objective (RPO). This also includes a test, that successful restoration is possible.
Technical specifications
Backups of system and application data must be created periodically and backups must be stored encrypted at a different location(s) for Business Continuity purposes. Keys need to be stored securely. The restore procedure must be tested yearly.
Create a backup strategy plan, with at least one offline backup system in place.
It is highly recommended to apply the 3-2-1 backup rule:
-Create 3 copies of your data (1 primary copy and 2 backups)
-Store your copies in at least 2 types of storage media (local drive, network share/NAS, tape drive, etc.)
-Store one of these copies offsite (I.e., in the Cloud)
There are sufficient recent copies (back-ups) of data and configurations for timely recovery of the service within its recovery norms; the recovery time objective (RTO) and the recovery point objective (RPO).
Rationale
Offline backups represent a critical safeguard for protecting essential data and systems against data loss, cyberattacks, and operational disruptions. When backups are stored exclusively within the same infrastructure or remain continuously connected to production environments, they may be compromised during incidents such as ransomware attacks, system failures, or malicious activity.
By maintaining offline backups that are geographically separated from the primary IT environment, organisations significantly reduce the likelihood that both primary systems and backup copies are affected simultaneously. This ensures that systems and data can still be restored even when the primary environment has been severely impacted.
Implementing a structured backup strategy, such as the 3-2-1 backup rule, strengthens data resilience by maintaining multiple copies of data across different storage media and locations. This approach improves the organisation’s ability to preserve the availability and integrity of critical information.
Defining restoration procedures and periodically testing recovery processes ensures that offline backups remain operationally effective. This enables the organisation to restore IT services within the defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), thereby supporting business continuity and operational resilience.
External reference
ISO/IEC 27001:2022 Annex A – A.8.13 Information backup (Primary) A.5.30 ICT readiness for business continuity A.8.24 Use of cryptographyIS.11.004. Communication Backup and Uptime
Description
The uptime percentage, the backup interval and backup retention periods are clearly communicated to users of the service.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
For users of IT services, it is essential to understand the availability levels and recovery capabilities associated with the services they rely on. When information regarding uptime, backup frequency, and backup retention periods is not clearly communicated, users may develop unrealistic expectations regarding service availability and data recovery possibilities.
By explicitly communicating these parameters, organisations provide transparency regarding service quality and the measures implemented to mitigate data loss and service disruptions. This enables users and service owners to make informed decisions regarding the use of the service and the storage of critical data.
Clear communication of backup policies and availability objectives also supports risk management and expectation management within the organisation. Users can align their operational processes with the actual recovery capabilities and availability levels of the IT services they depend on.
Documenting and communicating these parameters strengthens governance and accountability by demonstrating which service commitments are in place and how they align with the organisation’s continuity and availability requirements.
External reference
ISO/IEC 27001:2022 Annex A – A.5.23 Information security for use of cloud services (Primary) A.8.13 Information backup A.5.30 ICT readiness for business continuityIS.11.005. Disaster Recovery Plan
Description
A disaster recovery plan needs to be present for potential disaster scenario’s that could affect the availability of the IT Service.
The disaster recovery plan is reviewed at least annually.
The disaster recovery plan needs to be periodically tested. This can be (through tabletop readings or simulations , simulations, parallel test or full interruption), at least once every 2 years. , and a full parallel test or full interruption test at least once per 5 years.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
IT services are often critical to business operations and organisational service delivery. When these services are disrupted by incidents such as system failures, cyberattacks, natural disasters, or other major disruptions, significant operational and financial consequences may occur.
A formal Disaster Recovery Plan describes the procedures and measures required to restore IT systems and services following a major disruption. By defining recovery steps and responsibilities in advance, organisations can respond more effectively and efficiently during crisis situations.
Regular review of the disaster recovery plan ensures that the plan remains up to date and aligned with changes in IT systems, infrastructure, and business processes. This helps ensure that recovery procedures remain relevant and executable when a disruption occurs.
Periodic testing of recovery procedures verifies that the plan is operationally effective and that the organisation is capable of restoring systems and services within the agreed recovery objectives. This strengthens the reliability of recovery capabilities and improves the resilience of critical IT services
External reference
ISO/IEC 27001:2022 Annex A – A.5.30 ICT readiness for business continuity (Primary) A.5.29 Information security during disruption A.8.13 Information backupIS.12.001. DTAP
Description
All environments (Development, Test, Acceptance, and Production) must be clearly distinguishable, for example through different color schemes.
Limit access to development, testing, and acceptance environments based on the principle of least privilege.
On-premise and IaaS/PaaS environments
At least distinct environments for acceptance and production must exist. Where development activities occur, at least one distinct environment for development must be in place.
Each environment should be utilized strictly for its intended purpose. For example, the development environment should only be used for development activities, the acceptance environment for acceptance testing, and the production environment should only be used for deploying finalized, accepted changes.
Privileged access to the production environment must be strictly separated from privileged access to other environments.
Authentication to non-production environments should not occur through the production Identity Provider (IdP).
The acceptance environment must mirror the production environment as closely as possible, with the exception of not being publicly available.
Changes to the production environment must first be tested in the acceptance environment.
SaaS environments
Ensure that Service Level Agreements (SLAs) or equivalent contracts with the SaaS provider specify requirements for uptime, data integrity, and security measures.
From an information security perspective, having an acceptance environment is not mandatory for SaaS solutions. However, if an acceptance environment is procured for functional reasons, all stipulations concerning On-premise/IaaS/PaaS environments, as outlined above, must apply.
Technical specifications
Production, acceptance and testing environments should be seperated from each other on a network level. DTAP environments are not allowed to have direct connections with each other.
Development environments are assumed to be transient and hosted on individual developer workstations. Developer workstations cannot expose development environments to outside of the workstation. If a development environment is not hosted on a workstation then all the restrictions apply as if it is a test environment.
Limit access to the development, testing and acceptance environments by least privilege. If acceptance environments need to face the Internet for any reason, limit the accessibility by IP whitelisting. Access through VPN is preferred.
Development and test environments do not connect to the UU IdP. Acceptance environments connect to the acceptance UU IdP. Production environments connect to the production UU IdP.
Debugging information is turned off in production environments.
A unique naming convention is used for each network (DTAP) environment.
If the application is classified as sensitive on any axis the following applies: Developers should not have write access to the production environment. If this is unavoidable, make sure to use the 4-eyes principle when changing code in the production environment.
Rationale
The separation of development, test, acceptance, and production environments is a fundamental security control within secure software development and system operations. When these environments are not clearly separated, there is a risk that experimental code, untested configurations, or test data may inadvertently reach production systems, potentially resulting in service disruptions or security incidents.
By maintaining separate environments and ensuring that each environment is used strictly for its intended purpose, organisations can develop, test, and validate changes in a controlled manner before deployment to production. This reduces the likelihood that errors, vulnerabilities, or unauthorised modifications affect operational systems.
Restricting access according to the principle of least privilege and separating privileged access between production and non-production environments prevents developers or testers from making uncontrolled changes to critical systems. This supports controlled change management processes and reduces the risk of privilege misuse.
Furthermore, maintaining acceptance environments that closely resemble production environments improves the reliability of testing processes and reduces the risk of unexpected behaviour when changes are deployed to production. This strengthens both the stability and security of IT services.
External reference
ISO/IEC 27001:2022 Annex A – A.8.31 Separation of development, test and production environments (Primary) A.8.32 Change management A.5.15 Access control A.8.9 Configuration managementIS.12.002. Data for Testing
Description
No production information (o.a. sensitive production data, API keys, credentials, production server hostnames, …) is exposed or reused in environments other than for acceptance testing.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Development and testing environments typically operate with fewer security controls than production environments. When production data, such as sensitive information, API keys, credentials, or production system identifiers, is used in these environments, the risk of data exposure or unauthorised access to critical systems increases significantly.
Restricting or prohibiting the use of production data in non-production environments reduces the risk of exposing confidential information. This prevents sensitive data from being accessible to developers, testers, or systems that are not subject to the same security protections as production environments.
In cases where production data is required for acceptance testing, it should only be used under controlled conditions and with appropriate safeguards. Such safeguards may include data masking, anonymisation, or strict access restrictions to the relevant testing environment.
By implementing clear rules for the use of data in testing environments, organisations can better protect the confidentiality of information and ensure that development and testing activities do not introduce unintended risks to production systems.
External reference
ISO/IEC 27001:2022 Annex A – A.8.33 Test information (Primary) A.8.31 Separation of development, test and production environments A.5.15 Access controlIS.12.003. Changes to Production
Description
Last updated: 4-2-2021
Test results in acceptance are logged and kept for at least 1 year.
Sign-off on a change is documented before go-live.
4-eyes principle is applied to changes.
For major changes, rollback procedures are in place before the change is applied.
Technical specification:
–
IS.12.004. Secure Coding Training
Description
Developers are demonstrably familiar with secure coding practices.
Technical specifications
OWASP top vulnerabilities are known and prevented during the coding process.
Developers maintain “certified secure coder” e.g. CERT Secure coding: https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices?focusedCommentId=88044413
Rationale
Secure coding training ensures that developers understand how vulnerabilities originate and how to prevent them at the source. Eliminating flaws during development is more effective and less costly than detecting them later through testing or incident response.
By making developers proficient in established secure coding practices and familiar with common weaknesses such as those in the OWASP Top 10, the organization reduces the likelihood of introducing exploitable defects into applications. This directly strengthens the security posture of all systems that rely on internally developed software.
External reference
8.28 Secure Coding, 8.29 Security testing in development and acceptance, 5.34 Information security awareness, education and trainingIS.12.005. Static Code Analysis
Description
During development, static code analysis software is used to detect potential security design flaws.
Technical specifications
Static code analysis tools are used during software development to automatically analyse source code for potential security vulnerabilities, coding errors and design weaknesses before the software is deployed.
Examples of static code analysis tools can be found at: https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Rationale
Software vulnerabilities often originate during the development phase as a result of programming errors, insecure functions, or improper input validation. When such vulnerabilities are discovered later in the development lifecycle or after deployment, they may introduce significant security risks and require costly remediation efforts.
By applying static code analysis during development, potential security weaknesses can be identified automatically before the software is executed. Static analysis tools examine the source code for known vulnerability patterns, insecure programming practices, and deviations from established security standards.
Early detection of security issues supports the principle of “shift-left security,” where security controls are implemented as early as possible in the development lifecycle. This reduces the likelihood that vulnerabilities propagate into production environments and improves the overall security and quality of software systems.
Furthermore, static code analysis promotes consistent development practices by providing developers with structured feedback on security risks and code quality. Integrating analysis results into development workflows and code review processes helps ensure that security requirements are systematically applied throughout software development activities.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.29 Security testing in development and acceptance A.8.25 Secure development life cycleIS.12.006. Configuration Files
Description
Appropriate secrets management is applied to confidential information needed to develop and deliver the service.
No hardcoded credentials and configurations are present in source code but only in separate configuration files with appropriate security protections.
No sensitive information can be found in versioning information and older releases in version management systems. Configuration should be stored in environment variables or in versioned scripts that generate the configuration based on user input.
Technical specifications
Apply appropriate configuration hardening using CIS recommendations where available.
Place files with sensitive information outside public access.
Apply strict permissions on sensitive files.
Rationale
Configuration files and application settings frequently contain sensitive information, such as authentication credentials, API keys, or system configuration parameters. When such information is embedded directly in source code or stored within version control systems, there is an increased risk that the information may be inadvertently exposed or misused.
By managing secrets and configuration data separately from the source code, organisations can reduce the likelihood that sensitive information is distributed through code repositories, software packages, or development environments. This helps prevent confidential data from becoming accessible to unauthorised individuals or systems.
Applying appropriate security protections to configuration files, such as restricted access permissions and secure storage locations, supports controlled handling of sensitive configuration data. This reduces the risk that configuration information essential to system operation becomes publicly accessible or subject to misuse.
Proper management of configuration data and secrets also supports secure development practices and contributes to the consistent implementation of security controls throughout development and deployment processes.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.9 Configuration management A.5.34 Privacy and protection of PIIIS.12.007. Security Update Packaging
Description
Last updated: 28-4-2021
Security updates to software are not part of the normal release cycle for features but instead are released for currently supported versions of the software so they can be installed without functional testing.
Appropriate security is part of the core premise of any service and fixing security issues shall not only be done on the request of clients.
Technical specification:
–
IS.13.001. Administrator Data Access
Description
Only data owners have access to their data. Administrators and suppliers can only technically access the data through a break-glass procedure that involves business sign-off and consultation with the UU.
Technical specifications
Apply RBAC (Role Based Access controls).
Administrators group is removed from personal data storage and replace by a group with break the glass accounts.
Rationale
System administrators typically possess extensive technical privileges that enable them to manage systems and resolve operational issues. When such privileges also allow direct access to sensitive data, this creates an increased risk of unauthorised data access, privilege misuse, or unintended exposure of confidential information.
By enforcing the principle that only data owners have access to their data, access to sensitive information is limited to individuals with a legitimate business need. This significantly reduces the risk of data leakage or unauthorised data processing.
In situations where technical access is necessary, such as maintenance, troubleshooting, or incident response, a controlled break-glass procedure can be applied. Under this procedure, access is granted temporarily following explicit approval and oversight, ensuring that such access remains proportional and auditable.
The use of role-based access control and dedicated break-glass accounts ensures that administrative privileges are tightly managed and that exceptional access to sensitive data is properly authorised and traceable.
External reference
ISO/IEC 27001:2022 Annex A – A.8.2 Privileged access rights (Primary) A.5.15 Access control A.8.3 Information access restrictionIS.13.002. Email Data Leakage Protection
Description
The most common sources of dataleaks using corporate email are identified, and protective measures are in place to detect and prevent them, requiring extra prompts and automatic detection of potential leaks.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Email remains one of the most widely used communication channels within organisations and is also a common source of data leakage incidents. Unintentional disclosure of sensitive information, such as sending emails to incorrect recipients, attaching confidential documents, or sharing internal information with external parties, can lead to significant security and privacy risks.
By identifying the most common causes of data leakage through corporate email, organisations can implement targeted protective measures to prevent such incidents. These measures may include automated detection of sensitive information, warning prompts to users prior to sending messages, and technical controls designed to block or flag potentially inappropriate data transfers.
Such mechanisms help raise user awareness and support employees in making informed decisions when sharing information through email. This reduces the likelihood that sensitive data is inadvertently disclosed outside the organisation.
Additionally, monitoring and detection capabilities for potential email data leakage support improved risk management and contribute to compliance with internal information security policies and applicable regulatory obligations related to data protection.
External reference
ISO/IEC 27001:2022 Annex A – A.8.12 Data leakage prevention (Primary) A.8.16 Monitoring activities A.5.14 Information transferIS.13.003. Automatic Email Forwarding
Description
Automatic forwarding of corporate email to an external address is prohibited.
Technical specifications
Automatic forwarding of e-mail must be disabled. Exceptions for domains can be made based on a recurring review of the organizational links and the security policies on the forwarded domain.
Rationale
Automatic forwarding of e-mail to external addresses poses significant risks to confidentiality and control of information. The UU loses visibility in how our data is used, while e-mail often contains personal and / or confidential data. Prohibiting automatic forwarding reduces the risk of data breaches, misuse, or unauthorized access.
External reference
ISO/IEC 27001:2022 Annex A – A.8.12 Data leakage prevention (Primary) A.5.14 Information transfer, A.8.3 Information access restriction 5.15 Access Control, 8.10 Information deletion, 8.16 Monitoring activitiesIS.13.004. Data Exfiltration Detection and Prevention
Description
There are measures to prevent users from downloading entire datasets. Additionally, or if these measures cannot be implemented, alerting and monitoring for users downloading large amounts of information from the service is in place.
Technical specifications
Apply detection for animalities for data in motion; spikes in network usage/bandwidth.
Rationale
Unauthorised downloading of large datasets represents a significant risk to the confidentiality and protection of organisational information. Users who legitimately have access to systems may intentionally or unintentionally export or copy large volumes of data, potentially leading to data leakage or uncontrolled distribution of sensitive information.
By implementing technical measures that limit or detect large-scale data downloads, organisations can significantly reduce the risk of data exfiltration. Such measures may include restrictions on bulk data exports or monitoring mechanisms that detect unusual network activity and abnormal data transfer volumes.
Where preventive controls cannot be fully implemented, monitoring of data transfers and user activity provides an additional layer of protection. Detecting anomalous behaviour, such as sudden spikes in network usage, enables security teams to identify and investigate potential data leakage incidents at an early stage.
This control therefore supports a proactive approach to protecting sensitive information and helps prevent large volumes of data from leaving the organisation without appropriate oversight.
External reference
ISO/IEC 27001:2022 Annex A – A.8.12 Data leakage prevention (Primary), A.8.16 Monitoring activities, A.5.14 Information transferIS.13.005. Unintended Information Disclosure
Description
Applications and services are configured to not display information that is unnecessary.
Functionality is designed and configured to prevent enumeration of information.
Technical specifications
Information that should not be enumerable are: usernames, email-addresses, files, versioning information, server configuration and structure, endpoints and so forth.
Error messages should be compact and not contain any technical information about the environment.
Customize default error pages to display only necessary information, no (back-end) software titles version numbers etc.
Rationale
Unintended disclosure of technical or organisational information through applications and services can significantly assist attackers during reconnaissance activities. Information such as usernames, system structures, software versions or configuration details can be used to identify vulnerabilities and prepare targeted attacks.
By configuring applications to display only necessary information, the organisation reduces the likelihood that sensitive technical details become available to unauthorised parties. Preventing enumeration of information further limits the ability of attackers to systematically gather information about user accounts, files or system infrastructure.
Restricting the technical detail contained in error messages and default system responses provides an additional layer of protection. Detailed error messages may unintentionally reveal information about software components, configurations or system architecture that could assist attackers in identifying weaknesses.
This control therefore supports the principle of minimising information exposure and ensures that systems disclose only the information required for legitimate operation of the service.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.27 Secure system architectureIS.13.006. Printing Data-Leakage Prevention
Description
Printing services are appropriately protected to make sure information sent to printers is protected against unauthorized access.
Technical specifications
Direct access to printers through the network is limited, all printing is done through central print servers which require authentication/authorization by the UU IdP.
Network traffic (print jobs, management) to and from printers is encrypted. Print data at rest is encrypted on both the printer and the central print servers.
Print jobs can only be printed at, and retrieved from, the printers by the submitter of the print job.
Print jobs are safely removed after printing.
Print jobs that haven’t been printed will be safely removed after 24 hours.
All management of printers must be done via the authorized methods with auditing of changes. Access to the printer that is neither authorized printing nor authorized management must be rejected.
Rationale
Printing services can represent an overlooked source of potential data leakage because documents containing sensitive information may be temporarily stored in print queues, on printers or on central print servers. Without appropriate safeguards, unauthorised users may gain access to these documents by intercepting print jobs, retrieving unattended printouts or accessing printer configurations.
By routing printing activities through centrally managed print servers and requiring authentication and authorisation, organisations can ensure that only authorised users are able to submit and retrieve print jobs. Encryption of print traffic and stored print data further reduces the risk of interception or unauthorised access during transmission or storage.
Automatically deleting print jobs after printing or after a predefined retention period ensures that sensitive documents are not unnecessarily retained on printers or print servers. Auditing printer management activities additionally helps detect unauthorised configuration changes or misuse of printing infrastructure.
Together, these measures reduce the risk of information disclosure through printing services and support controlled and secure handling of organisational information.
External reference
ISO/IEC 27001:2022 Annex A – A.8.12 Data leakage prevention (Primary), A.5.15 Access control, A.8.24 Use of cryptographyIS.13.007. AI training Data-Leakage Prevention
Description
AI tools do not use production data, including user prompts, to (further) train the underlying AI models. This also prohibits the entry of data (including questions from which sensitive matters can be derived) with confidentiality ‘1. Basic’ or higher in tools where it is not explicit that this data may not be used.
AI tools are only allowed if they assure the UU that all UU prompts and answers are not used to train the model. Models trained on UU training data may only be used within the context of the UU.
Technical specifications
This applies to all AI tools such as machine learning platforms, natural language processing systems and other AI-driven applications.
AI tools and systems should perform data sanitization to prevent user data entering the training model.
Rationale
AI systems frequently process user inputs and generated responses as part of their learning mechanisms. When production data or user prompts are automatically incorporated into model training processes, sensitive organisational information may unintentionally become part of training datasets. This can lead to uncontrolled information exposure or unintended disclosure through model outputs.
Restricting the use of production data for AI model training prevents organisational information from being incorporated into external or shared AI models. This is particularly important when AI tools are provided by external vendors who may reuse submitted data to improve underlying models.
Implementing data sanitisation and clear governance rules regarding the use of training data helps ensure that sensitive information is not unintentionally processed within AI training pipelines. This maintains organisational control over how data is used in AI systems.
This control therefore supports the secure adoption of AI technologies by preventing confidential information from being incorporated into AI training datasets or model behaviour.
External reference
ISO/IEC 27001:2022 Annex A – A.8.12 Data leakage prevention (Primary) A.5.14 Information transfer A.5.23 Information security for use of cloud servicesIS.13.008. Restriction of device and application access
Description
To ensure the confidentiality and integrity of UU data, only devices and services that have been explicitly approved within UU and comply with the relevant provisions in the Security Control Framework (SCF) are permitted to access data and systems authenticated via the UU Identity Provider (IdP).
This policy applies to both physical devices and external (cloud) services that authenticate via the IdP and subsequently gain access to applications, communication platforms, or other institutional resources. Access is limited to approved services and to devices that meet the required security posture for the requested data and functionality.
Non-managed devices and services that do not meet these requirements are not permitted to establish access through the IdP, preventing unauthorized or uncontrolled data exposure.
Technical specifications
To allow access to services the IdP can use blocklists or allowlists. The IdP is allowed to check if connecting devices meet stated requirements and deny access if these requirements are not met.
Rationale
The core risk lies less in the physical devices and more in external services that authenticate through the IdP and gain access to UU data. Such services can assume a user’s identity, link IdP sessions to their own ecosystems, and store or process institutional data outside UU’s control—often without the user realizing it. This erodes our ability to manage authentication, authorization, and data protection. By allowing only managed and explicitly approved devices and services to authenticate via the IdP, we prevent uncontrolled cloud platforms or “smart” service ecosystems from acting as UU users and extracting or retaining data in external environments. This keeps identity access governed and ensures UU data remains within secure, compliant boundaries.
External reference
ISO/IEC 27001:2022 Annex A – A.5.15 Access control (Primary) A.8.2 Privileged access rights A.8.12 Data leakage preventionIS.14.001. Application Session Management
Description
Last updated: 28-4-2021
Applications need to implement session timeouts and verify against the Identity Provider if the User still has a valid session.
Technical specification:
Sessions are managed according to NIST Special publication 800-63 Section 7.1 https://pages.nist.gov/800-63-3/sp800-63b.html.
IS.14.002. Input and Output Filtering
Description
All variable information that gets sent by a client is filtered and sanitized before processed in the application. The same applies to user-chosen output that is presented back to users. This avoids any unintentional side-effect of processed data.
Technical specifications
Any input and output will adhere to the concept of ‘do not trust user in/output’.
Any data entered by the user or processed as result of earlier entry should be handled in such a way it can’t cause any side-effects in the application.
In web application programming this means avoiding sql-injection, cross-site scripting and any other influence on the application or on the presentation to the user.
In network traffic handling this means avoiding any side-effects or even crashes such as ping-of-death or other attacks on network stacks.
This also applies to third-party software used in data processing which must be updated when vulnerabilities are found
Rationale
Applications frequently process data originating from users, external systems or network traffic. When such input is not properly validated or filtered, attackers may manipulate application behaviour by submitting malicious input that exploits vulnerabilities within the application logic. Examples include injection attacks such as SQL injection, cross-site scripting or manipulation of network protocols.
By validating and sanitising all input and output before processing or displaying it, organisations significantly reduce the risk that malicious input can influence application behaviour. This approach aligns with the security principle that user-provided or externally supplied input must always be considered untrusted until it has been explicitly validated.
Applying input and output filtering also prevents applications from unintentionally returning unsafe content or executable code to users, which could otherwise lead to exploitation of application functionality or information disclosure.
This control therefore supports secure application development by ensuring that applications handle external input safely and by reducing vulnerabilities caused by untrusted data processing.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.29 Security testing in development and acceptance A.8.27 Secure system architectureIS.14.003. Web Application Security
Description
Web applications have taken all appropriate measure to protect against OWASP top 10 Web Application vulnerabilities: https://owasp.org/www-project-top-ten/
Technical specifications
Web applications must implement appropriate security measures to mitigate the risks associated with the OWASP Top 10 Web Application vulnerabilities.
Cookies must be configured with the following security flags by default:
Secure
HttpOnly
Domain=[domain]
SameSite=Strict
Cross-Origin Resource Sharing (CORS) must be configured in such a way that only required access is permitted and unnecessary cross-origin requests are prevented.
Rationale
Web applications frequently serve as direct entry points to organisational systems and data, making them a primary target for attackers. Vulnerabilities in web applications can lead to unauthorised access to information, manipulation of application behaviour or disruption of services.
The OWASP Top 10 provides a widely recognised overview of the most common web application security risks. By implementing security measures that address these risks during development and configuration, organisations significantly reduce the likelihood that known vulnerabilities can be exploited.
Proper configuration of security mechanisms such as cookie attributes and Cross-Origin Resource Sharing (CORS) policies further protects web applications against session hijacking, client-side script access to cookies and unauthorised cross-origin access to application resources.
This control therefore supports secure web application development and configuration practices and helps prevent exploitation of well-known application vulnerabilities.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.27 Secure system architecture A.8.29 Security testing in development and acceptanceIS.14.004. Mobile Applications
Description
Mobile Applications use certificate pinning to prevent MitM attacks on apps and Open WiFi.
Mobile applications have protections for the binaries that users can download.
Mobile apps preferably store information encrypted and containerized.
Sensitive information must be stored server-side unless specifically needed for functioning of the application.
Technical specifications
Mobile applications implement platform security protections such as Position Independent Code (PIC) and Address Space Layout Randomization (ASLR) to mitigate exploitation of memory vulnerabilities.
Applications follow the National Cyber Security Centre (NCSC) guidelines for mobile applications, particularly regarding secure data storage and protection of application data on mobile devices.
Rationale
Mobile applications are often used in environments where both the network and the device itself are less controlled than traditional enterprise environments. As a result, mobile applications are exposed to increased risks such as man-in-the-middle attacks, application binary manipulation and unauthorised access to locally stored data.
Implementing security mechanisms such as certificate pinning helps prevent interception or manipulation of network traffic between mobile applications and backend systems. Protecting application binaries and applying security mechanisms such as Position Independent Code (PIC) and Address Space Layout Randomization (ASLR) reduces the risk that software vulnerabilities can be exploited.
Limiting the storage of sensitive data on mobile devices further reduces the risk of data exposure if a device is lost, stolen or compromised. When local storage is required for application functionality, data should be encrypted and protected using appropriate security mechanisms.
These measures strengthen the security posture of mobile applications and help protect the confidentiality and integrity of organisational data processed through mobile platforms.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.27 Secure system architecture A.8.24 Use of cryptographyIS.14.005. Application (D)DoS Protection
Description
The application has taken application level steps to prevent Denial of Service attacks such as caching where possible, CAPTCHA, rate limiting and designing functionality to be non-blocking..
This includes protecting API endpoints against executing requests that could lead to DoS, limiting upload field data size and locking out users through reset functionality.
Technical specifications
The application has been developed in a secure way.
A CAPTCHA is used to protect authentication methods.
Rationale
Mobile applications are often used in environments where both the network and the device itself are less controlled than traditional enterprise environments. As a result, mobile applications are exposed to increased risks such as man-in-the-middle attacks, application binary manipulation and unauthorised access to locally stored data.
Implementing security mechanisms such as certificate pinning helps prevent interception or manipulation of network traffic between mobile applications and backend systems. Protecting application binaries and applying security mechanisms such as Position Independent Code (PIC) and Address Space Layout Randomization (ASLR) reduces the risk that software vulnerabilities can be exploited.
Limiting the storage of sensitive data on mobile devices further reduces the risk of data exposure if a device is lost, stolen or compromised. When local storage is required for application functionality, data should be encrypted and protected using appropriate security mechanisms.
These measures strengthen the security posture of mobile applications and help protect the confidentiality and integrity of organisational data processed through mobile platforms.
External reference
ISO/IEC 27001:2022 Annex A – A.8.28 Secure coding (Primary) A.8.27 Secure system architecture A.8.24 Use of cryptographyIS.14.006. Malware Scanning
Description
Any central system, application or server, that stores and serves files or links to users shall scan attachments, uploads and links for malware and block access to content identified as harmful by these scans.
Workstations that process these sorts of content also scan for malicious content, controls are based on IS.8.006.
Technical specifications
All malware scanning should have signature and heuristic behavioural capabilities. The scans should also adhere to all other security controls in this framework related to anti-malware tooling.
All positive malware scans should be checked regularly by IT personnel.
In the case of attachment scanning, the scanning should be done before the email is delivered to the user’s inbox. If malware is found, the e-mail can still be delivered, but without the attachment.
In the case of uploads the scan should be done before an upload becomes available to the application for further use and be done again on access.
In the case of links the scan should be done before the user is able to visit the link.
Rationale
Systems and applications that process files, attachments or hyperlinks represent a common entry point for malware within organisational environments. Malicious software may be delivered through email attachments, uploaded files within applications or links to external resources, potentially leading to system compromise, data loss or service disruption.
By performing malware scanning before such content becomes accessible to users, organisations can prevent harmful files or links from being executed within their systems. Combining signature-based detection with heuristic or behavioural analysis increases the likelihood of identifying both known and previously unknown malware.
Scanning files at multiple stages in the processing lifecycle, such as upon receipt, upload and access, further reduces the risk that malicious content can propagate undetected through organisational systems. Additionally, periodic review of malware detection events by authorised IT personnel helps ensure that potential security incidents are investigated and addressed promptly.
This control therefore strengthens protection against malware infections and supports secure handling of files and links within applications and services.
External reference
ISO/IEC 27001:2022 Annex A – A.8.7 Protection against malware (Primary) A.8.16 Monitoring activities A.8.28 Secure codingIS.14.007. Third Party Apps and Libraries
Description
A documented risk analysis is available for each third-party app used by the application.
Third party apps and libraries are tracked for vulnerabilities and security updates as part of the main app.
Technical specifications
A documented risk analysis must be available for each third-party application, library or software component used within the application.
The risk analysis must at least address:
whether the third-party components have been assessed for security vulnerabilities
whether security testing is performed on these components as part of penetration testing or application security testing
the benefits and functional requirements for using the third-party component
the potential risks introduced by integrating the third-party component
how the component is maintained, updated and patched throughout its lifecycle
Third-party applications and libraries must be monitored for security vulnerabilities and updates. Vulnerability tracking and patch management for these components must be integrated into the application’s security maintenance process.
Only third-party software that has been assessed and deemed sufficiently secure may be used within the application.
Rationale
Modern applications frequently rely on third-party software components, libraries and frameworks to accelerate development and extend functionality. While these components provide significant benefits, they may also introduce security risks if vulnerabilities exist within the external software or if the components are not properly maintained.
Vulnerable or outdated third-party components can be exploited by attackers to gain unauthorised access to applications or sensitive information. For this reason, it is necessary to perform a documented risk assessment before integrating such components, evaluating both their functional benefits and their potential security risks.
In addition, organisations must continuously monitor third-party components for newly discovered vulnerabilities and ensure that security updates are applied in a timely manner. Integrating the maintenance and patch management of external components into the application lifecycle helps reduce the risk that vulnerabilities within dependencies lead to security incidents.
This control therefore supports secure software development by ensuring that dependencies on external software components are properly assessed, monitored and maintained.
External reference
ISO/IEC 27001:2022 Annex A – A.8.25 Secure development life cycle (Primary) A.8.29 Security testing in development and acceptance A.8.8 Management of technical vulnerabilitiesIS.14.008. Application Authorisations
Description
Authorisations are preferably centrally managed.
Technical specifications
Access to an application is authorized by its owner.
Rationale
Applications often contain sensitive information and functionality that should only be accessible to authorised users. When authorisations are not clearly managed or are not linked to defined organisational responsibilities, there is an increased risk that users may obtain unauthorised access to applications or specific functions.
Requiring authorisation decisions to be approved by the designated application owner ensures that access is granted based on legitimate business needs and organisational accountability. The application owner is responsible for determining which users require access in order to perform their duties.
Centralised authorisation management further supports consistent access control policies and enables organisations to manage, review and revoke access rights more effectively.
This control therefore supports controlled and accountable assignment of access rights to applications and helps prevent unauthorised access to organisational systems and information.
External reference
ISO/IEC 27001:2022 Annex A – A.5.15 Access control (Primary) A.8.2 Privileged access rights A.5.18 Access rightsIS.15.001. Default Passwords changed
Description
Default Passwords on any piece of hardware or software are changed before it is deployed.
Technical specifications
Universal and/or default passwords must not be used.
For existing systems that have built-in default passwords, these can only be used one time, after logging on this password must be changed. The new password meets our password complexity standards as described in IS.9.002 and are handled as confidential information, see DS.2.005.
Rationale
Many hardware and software products are delivered with default credentials intended for initial configuration or installation. These default passwords are often publicly documented or easily discoverable through vendor documentation. If such passwords are not changed before systems are placed into operation, unauthorised individuals may gain access to systems or administrative interfaces with minimal effort.
Changing default passwords before systems are deployed prevents attackers from exploiting known or predictable authentication credentials. This significantly reduces the risk of unauthorised access to systems and administrative functions.
Applying organisational password requirements further ensures that authentication credentials meet defined security standards. Treating passwords as confidential information also helps prevent unintended disclosure or misuse.
This control supports secure system configuration practices and helps prevent basic configuration weaknesses from resulting in unauthorised access to organisational systems.
External reference
ISO/IEC 27001:2022 Annex A – A.8.9 Configuration management (Primary) A.5.17 Authentication information A.5.15 Access controlIS.15.002. Service Hardening
Description
Assets should be hardened. The attack surface should be reduced where possible, through minimalization, least privilege and effective use of available controls.
Technical specifications
Systems and services must be hardened to reduce their attack surface and limit potential exploitation vectors.
Only services that are strictly required for the operation of the system should be installed and running.
Host-based firewalls should be used to restrict network access to the system, in accordance with IS.8.013.
Services must run under dedicated service accounts with the minimum privileges required to perform their function. Where elevated privileges are temporarily required during startup, these privileges must be dropped as soon as possible.
Security mechanisms such as Application Control, SELinux, AppArmor or comparable system hardening technologies should be used where available to restrict application capabilities.
Services must be configured according to secure configuration best practices in order to minimise information exposure and reduce the potential for exploitation.
Rationale
Systems often include multiple services and functionalities by default that are not required for delivering a specific IT service. These unnecessary services increase the system’s attack surface and may introduce vulnerabilities that attackers can exploit.
Hardening systems and services reduces this attack surface and lowers the likelihood that vulnerabilities in unused or unnecessary services can be exploited. This is achieved by limiting installed services to those strictly required, applying access control mechanisms, and restricting process privileges to the minimum level necessary for their operation.
Additional security mechanisms such as host-based firewalls and application control technologies further help prevent unauthorised access to services and limit unintended functionality.
This control supports secure system configuration practices and helps prevent unnecessary services or excessive privileges from creating exploitable security weaknesses.
External reference
SO/IEC 27001:2022 Annex A – A.8.9 Configuration management (Primary) A.8.8 Management of technical vulnerabilities A.5.15 Access controlIS.15.003. Server and Application Infrastructure Not Shared
Description
IT services run in their own virtual environments, vulnerabilities in one service cannot give access to other services. This includes no multiple websites on the same webserver unless they share the same Security Capability Level and purpose, the same applies to databases between different services.
Technical specifications
Every newly deployed server has a maximum of one role.
Rationale
When multiple applications or services are hosted on the same infrastructure components, a vulnerability in one application may lead to unauthorised access to other systems or data. This increases the risk of lateral movement within the IT environment and may allow security incidents to escalate.
Isolating IT services within separate virtual or logical environments prevents vulnerabilities in one system from directly affecting other services. Limiting servers to a single primary role also reduces system complexity and makes it easier to apply secure configurations and maintain consistent security controls.
This control supports the principle of minimal functionality and infrastructure segregation, thereby reducing the attack surface of systems and limiting the potential impact of security incidents.
As a result, the organisation maintains a more secure and manageable IT infrastructure in which applications, databases and services are not unnecessarily dependent on shared infrastructure components.
External reference
ISO/IEC 27001:2022 Annex A – A.8.9 Configuration management (Primary) A.8.22 Segregation of networks A.5.15 Access controlIS.15.004. White-Listed Applications
Description
Servers used in delivering the IT service only allow whitelisted executables.
Where possible, the integrity of executables is confirmed using integrity hashes .
Technical specifications
Non-privileged users are prohibited to run unauthorised software on common workspace servers.
Rationale
Servers supporting IT services are attractive targets for attackers attempting to execute unauthorised software such as malware, backdoors or scripts used for lateral movement within the infrastructure. If systems allow arbitrary software execution, the attack surface of the environment increases significantly.
Application allow-listing restricts execution to software that has been explicitly approved. This prevents unauthorised applications or scripts from running on servers that support critical services.
Verifying the integrity of executable files using cryptographic hashes or similar mechanisms further ensures that approved software has not been altered or replaced with malicious versions.
This control reduces the attack surface of servers and supports controlled and secure execution of software within the IT infrastructure.
External reference
ISO/IEC 27001:2022 Annex A – A.8.9 Configuration management (Primary) A.8.7 Protection against malware A.8.8 Management of technical vulnerabilitiesIS.15.005. Portable Media Hardware Protection
Description
Peripheral devices, such as USBs, are validated by separate systems designed specifically to validate the security of the devices. Only after this validation can these devices be inserted into hardware used to deliver the IT service.
Technical specifications
These validation systems must be kept up-to-date, on a separate network, run a minimum of 2 anti-virus packages from separate vendors with up-to-date signatures and perform detection for malware. These systems have detection and protection against USB-killer functionality and are re-imaged daily.
Rationale
Removable media such as USB devices represent a well-known risk to IT environments because they may introduce malware or manipulated hardware into systems. When such devices are connected directly to production systems, there is a risk that malicious software may be executed or that hardware-based attacks may damage systems.
Validating removable media through dedicated validation systems prevents potentially harmful devices from directly accessing critical infrastructure. These validation systems are specifically designed to detect malware, identify suspicious files and detect potential hardware manipulation.
Using multiple detection mechanisms and segregated validation environments reduces the likelihood that infected media can reach production systems. Regular updates and periodic re-imaging of validation systems help ensure that these systems remain reliable and trustworthy.
This control reduces the risk that malware or malicious hardware introduced through external media can compromise systems supporting IT services.
External reference
ISO/IEC 27001:2022 Annex A – A.8.7 Protection against malware (Primary) A.8.9 Configuration management A.5.14 Information transferIS.15.006. Disk Encryption or Removal Protection
Description
Storage disks have appropriate FDE enabled equivalent to endpoint protection, or appropriately secure datacentre security controls are in place to prevent removal of storage devices.
Technical specifications
Data sent on physical media such as USB sticks must be encrypted using up-to-date encryption standards.
Use BitLocker To Go or the encryption product of a preferred supplier.
UU internal link on disk encryption
Rationale
Storage devices such as hard drives, solid-state drives and removable storage media may contain sensitive organisational information. If such media are removed, lost or stolen, there is a risk that the stored data could be accessed by unauthorised individuals.
Applying full disk encryption ensures that data stored on the device is protected and cannot be accessed without the appropriate cryptographic keys. This maintains the confidentiality of the information even if the physical storage device falls into the hands of an unauthorised party.
In environments where storage media are located within secured datacentre facilities, physical security controls may additionally prevent unauthorised removal of storage devices.
This control helps protect information stored on organisational systems and reduces the risk that loss or theft of storage media results in a data breach or unauthorised access to sensitive information.
External reference
ISO/IEC 27001:2022 Annex A – A.8.24 Use of cryptography (Primary) A.7.9 Security of assets off-premises A.8.9 Configuration managementIS.15.007. Legacy Systems
Description
Legacy Systems are systems that are End-of-Support (including no longer supported through ‘extended support’).
Legacy Systems that need to be maintained are kept as isolated as possible and are segmented only with other legacy systems they need to interface with. Access to non-legacy services occurs through secure Bastions. Security of production services is not downgraded for compatibility with legacy systems. Legacy systems have no access to the internet.
Where possible Legacy Systems are virtualized.
Where possible complete system images and backups are available for legacy systems.
There is additional security monitoring for Legacy systems.
Technical specifications
Operational implementation of this control is defined and maintained by Security Operations and relevant platform teams.
Detailed procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Systems that are no longer supported by their vendors do not receive security updates or patches. As a result, vulnerabilities may exist that cannot be remediated and may be exploited by attackers to gain access to systems or data.
When legacy systems must remain operational for business reasons, it is essential to limit the risks associated with these systems by applying additional security controls. Isolating legacy systems from standard production environments and implementing network segmentation helps ensure that vulnerabilities in legacy systems cannot easily affect other services.
The use of bastion hosts, enhanced monitoring and restricted network connectivity reduces the likelihood that legacy systems can be used as an entry point for broader infrastructure compromise.
This control ensures that legacy systems remain manageable and that the overall security posture of production services is not weakened by the presence of unsupported systems.
External reference
ISO/IEC 27001:2022 Annex A – A.8.8 Management of technical vulnerabilities (Primary) A.8.22 Segregation of networks A.8.16 Monitoring activitiesIS.16.001. Organizational Data Deletion
Description
Last updated: 30-7-2020
After the retention period or when the data medium is decommissioned, lost or repurposed, organization data is deleted.
End users receive sufficient warning before data is deleted.
Technical specification:
Deleting takes place according to NIST Guidelines for Media Sanitization for the level of ‘Clear’ or higher: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
IS.16.002. Purging of Data Media
Description
When the data medium containing data that might be classified with confidentiality of Critical is decommissioned, lost or repurposed, that data needs to be purged.
Destruction of encryption keys is considered equivalent to data purging.
A declaration of data purging must be demonstrable on request.
Technical specifications
Data deletion and media sanitization must follow recognised standards for secure data removal.
When data media containing information classified as Confidentiality: Critical are decommissioned, lost or repurposed, the stored data must be securely purged.
Secure deletion must follow NIST SP 800-88 Rev.1 – Guidelines for Media Sanitization, at the level of “Purge” or higher.
Reference:
https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final
Destruction of encryption keys protecting the data is considered equivalent to data purging when cryptographic erasure renders the stored data unreadable.
Where physical destruction of storage devices is required, this must be performed by an approved supplier capable of providing evidence of secure destruction.
Evidence of data sanitization or destruction must be demonstrable upon request.
Rationale
When storage media are decommissioned, repurposed or lost, there is a risk that previously stored information may still remain accessible on the device. If such data is not securely removed, unauthorised individuals may recover the information using data recovery techniques.
Applying recognised data sanitization standards ensures that information cannot be reconstructed once the storage medium has been retired or reused. Cryptographic erasure, achieved by securely destroying encryption keys protecting the stored data, can provide an effective alternative method when data has been encrypted.
Maintaining evidence that data has been securely purged is important for accountability and compliance, particularly during audits or incident investigations.
This control ensures that sensitive information is not left accessible on storage media that are no longer in active use, thereby reducing the risk of unauthorised disclosure of organisational data.
External reference
ISO/IEC 27001:2022 Annex A – A.8.10 Information deletion (Primary) A.7.14 Secure disposal or reuse of equipment A.8.24 Use of cryptographyIS.17.001. Encrypted Connections
Description
All data in transit is encrypted.
Technical specifications
For TLS based protocols including but not limited to https use the latest version of our deep dive on TLS, available at https://solisservices.sharepoint.com/:w:/s/10824/EWufJC7WWJVIr3eKqOBVc88BimyCynLCKAhmGa7mn5B7Mg
For TLS we use certificates that are managed according to certificate management (IS.20.001)
For other encrypted protocols: the same choices in enabling and disabling key exchange, hashing and bulk encryption algorithms to get the same level of confidentiality, integrity and non-repudiation.
Rationale
When information is transmitted between systems or users across networks, there is a risk that the data could be intercepted or altered by unauthorised parties. Without appropriate protection, this may result in loss of confidentiality, integrity or authenticity of the transmitted information.
Applying encrypted communication protocols ensures that data in transit is protected against interception and tampering. Encryption mechanisms ensure that only authorised parties are able to access the contents of the communication.
The use of standardised cryptographic protocols and centrally managed certificates helps maintain consistent and secure configurations of communication channels.
This control supports secure communication between systems and users and helps prevent sensitive information from being exposed during transmission.
External reference
ISO/IEC 27001:2022 Annex A – A.8.24 Use of cryptography (Primary) A.5.14 Information transfer A.8.20 Network securityIS.17.002. Official Mails Sent From Organisational Address
Description
The IT services send emails to end-users using an email address ending in a top-level domain for which the organisation is legally responsible.
Technical specifications
Services sending mail, from primary domains uu.nl or students.uu.nl, on behalf of the UU send mail via the UU SMTP relay infrastructure, using SMTP credentials provided by the UU. This communication is done over encrypted connections to the UU infrastructure. SMTP with STARTTLS and SMTPS (secure SMTP) are both allowed. The authentication phase can only start after an encrypted connection has been established.
Services sending mail from non-primary (sub-)domains, like mail.uu.nl, can send that mail from their own SMTP infrastructure. The mail still needs to comply with all other technical requirements. These services can use the RETURN-PATH mail header, which helps to track bounces. Changes to UU subdomain SPF records are not allowed.
Forwarding e-mail on behalf of the UU from a service purely based on the originating IP address is not allowed.
Rationale
Organisations send significant volumes of email to internal and external recipients. When systems are able to send emails from organisational domains without adequate controls, there is a risk of spoofing, phishing or misuse of the organisation’s identity.
By requiring that emails sent on behalf of the organisation originate only from domains for which the organisation is legally responsible and are transmitted via controlled SMTP infrastructure, the origin of organisational email communications becomes verifiable and manageable.
Using centralised email infrastructure and encrypted communication channels also helps ensure the integrity and confidentiality of email transmission. In addition, this enables the application of further security mechanisms such as SPF configuration, monitoring and misuse detection.
This control contributes to protecting the organisation’s reputation, preventing misuse of organisational domains and ensuring trustworthy communication with users.
External reference
ISO/IEC 27001:2022 Annex A – A.5.14 Information transfer (Primary) A.8.24 Use of cryptography A.8.20 Network securityIS.17.003. Mailserver Security
Description
Mailservers take measures to prevent the reception and transmission of spam and malicious mails.
Mails should be revocable on managed servers and supported endpoints.
Links in emails should be validated to not be malicious.
Mailserver reputation is monitored. Thresholds are determined and actions are taken to improve the reputation if it falls below thresholds.
Technical specifications
All e-mail servers that handle UU e-mail need to implement the following for both incoming and outgoing mail flows (where applicable):
SPF minimized to just allowed senders. In practice this would be Microsoft and ITS. Recursive lookups for SPF records are limited to 10 DNS lookups, including nested records.
DKIM signing of outgoing mail is implemented for all domains and subdomains. The key algorithm should be RSA with a key size of at least 2048 bit and a lifetime of at most 2 years. Hashing needs to be done with SHA-256.
DMARC implemented with ‘quarantaine’ policy.
DNSSEC is implemented on all e-mail related DNS records.
IPv4 and IPv6 are both available.
Security monitoring is setup on e-mail servers. Contact UU ITS Security Operations for details.
All connections to the e-mail servers need to be authenticated. Only servers sending e-mail to non-end-users, like sysadmins, can be done without authentication. In this case the servers should be whitelisted based on IP. Authentication based on machine or application identity is preferred for mail from systems or applications.
All connections to send mail or receive/read mail to/from e-mail servers are encrypted. STARTTLS is allowed to negotiate an encrypted connection.
All e-mail servers have anti-malware and spam filter tooling running on all in- and outgoing e-mail traffic.
E-mail is only sent from/to domains where this is explicitly authorized. All domain and subdomains for which the UU is responsible, that do not send mail need to set the following DNS records by default:
-TXT v=spf1 -all
-TXT “v=DMARC1; p=reject;”
-MX “0 . ”
Rationale
Email is one of the primary communication channels within organisations and simultaneously one of the most common vectors for cyber attacks. Without adequate security controls, mail servers can be exploited to distribute spam, phishing messages or malware.
Implementing domain authentication mechanisms such as SPF, DKIM and DMARC allows organisations to verify the legitimacy of sending domains and prevents spoofing of organisational email domains. In addition, spam and malware filtering capabilities help detect and block malicious messages before they reach users.
Encrypted transport protocols and authentication mechanisms protect the confidentiality and integrity of email communications during transmission. Monitoring the reputation of mail servers enables organisations to detect abuse of their email infrastructure and take corrective action before reputational damage occurs.
This control supports secure electronic communication and helps prevent organisational email infrastructure from being abused for cyber attacks or data leakage.
External reference
ISO/IEC 27001:2022 Annex A – A.8.7 Protection against malware (Primary) A.5.14 Information transfer A.8.24 Use of cryptography A.8.20 Network securityIS.17.004. Mailsender Non-Repudiation
Description
Mail can only be sent by the owner of the mailbox or explicitly authorized individuals. All mails and actions are traceable to the individual.
Technical specifications
Operational implementation details for this control are defined and maintained by Security Operations and relevant platform teams.
Technical procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Email communication plays a central role in organisational processes and is frequently used for formal communication with internal and external stakeholders. When emails can be sent without clear attribution to an individual user, there is a risk that actions cannot be traced to a responsible party.
Ensuring that emails can only be sent by the mailbox owner or by explicitly authorised individuals and that all email activities are traceable to an individual establishes accountability in email communication.
Traceability of email activities also supports incident investigations, detection of misuse and enforcement of organisational policies.
This control contributes to trustworthy communication and helps prevent email accounts from being abused for fraudulent or unauthorised activities.
External reference
ISO/IEC 27001:2022 Annex A – A.5.15 Access control (Primary) A.8.15 Logging A.8.16 Monitoring activitiesIS.17.005. Domain reservations
Description
Domain names reserved for organisational purposes cannot be released shortly after the domain name is no longer needed.
A list of domain names that can never be released needs to be kept.
Domain names not on this list need to remain reserved with a placeholder message that the domain is no longer in use by the organisation for 3 years before they can be released and used by other partie
Technical specifications
Operational implementation details for this control are defined and maintained by Security Operations and relevant platform teams.
Technical procedures, tooling configurations and operational workflows are documented in operational runbooks and platform-specific implementation standards.
Rationale
Domain names form an important part of an organisation’s digital identity. When domains previously used by the organisation are released, they may be registered by external parties and used for fraudulent activities.
For example, attackers may use such domains to conduct phishing campaigns where emails or websites appear to originate from the organisation. Because users often trust familiar domain names, these attacks can be particularly effective.
By retaining unused domains for a defined transition period and maintaining a list of domains that must never be released, the organisation reduces the risk that previously used domains are re-registered and misused.
This control helps protect the organisation’s digital identity and reduces the risk of phishing, impersonation and reputational damage caused by abandoned domains.
External reference
ISO/IEC 27001:2022 Annex A – A.5.14 Information transfer (Primary) A.8.20 Network securityIS.17.006. Labelled External Communication
Description
Communication coming from outside the organisation needs to be clearly marked with warnings that the originating party is from outside the organisation. This includes electronic messages received in email programs.
Technical specifications
The warning message in e-mail needs to mention to handle suspicious emails carefully (not click on links without checking) and that suspicious emails and (potential) incidents need to be reported to CERT-UU.
Other communication channels in which identities can be mistaken and impersonated must also be labelled to aid the user in recognizing external sources.
Rationale
Phishing and social engineering attacks frequently rely on email messages or other communication channels that appear to originate from trusted internal sources. When users cannot easily distinguish whether a message originates from outside the organisation, the likelihood of successful deception increases.
By clearly labelling external communications with warning messages, users are better able to recognise that a message originates from an external source. This helps users identify suspicious messages and reduces the risk of phishing or impersonation attacks.
Displaying warnings also supports organisational incident response processes by encouraging users to report suspicious communications to the security team.
This control contributes to reducing the likelihood of successful phishing attacks and promotes safer handling of electronic communications.
External reference
ISO/IEC 27001:2022 Annex A – A.6.3 Information security awareness, education and training (Primary) A.5.14 Information transfer A.8.16 Monitoring activitiesIS.18.001. Incident Response Process
Description
An incident response process for dealing with incidents in IT services is in place
The incident response process has processes for dealing with security incidents
Security incidents are escalated appropriately.
Security incidents are evaluated.
Information on security incidents is handled on a need-to-know basis.
Security incidents involving personal data are also seen as possible data breach and handled accordingly.
Technical specifications
IT security incident handling needs mandate to take preventive measures to stop a security incident from causing (more) damage
The security incident process has 6 phases
– Preparation: information needed to handle security incidents is available to security incident handlers and they are trained in handling these incidents
– Identification: incidents that happen are detected, classified, registered and handled
– Containment: the impact of the security incident is minimized
– Eradication: the cause of the incident is stopped
– Recovery: service is returned to normal
– Lessons learned: the incident is evaluated and improvements are recorded
More information on computer security incident handling teams in Guide to setting up a Computer Security Incident Response Team (CSIRT):
https://www.enisa.europa.eu/publications/csirt-setting-up-guide/at_download/fullReport
Rationale
Security incidents may result in disruption of IT services, loss of data or unauthorised access to information. Without a structured incident response process, organisations cannot effectively respond to security incidents or limit their impact.
Establishing a formal incident response process that includes clearly defined phases such as identification, containment, recovery and evaluation enables organisations to detect and manage security incidents in a timely and controlled manner.
The process also ensures that incidents are escalated appropriately and that incident-related information is shared only with individuals who require it to perform their responsibilities.
Including a “lessons learned” phase ensures that incidents contribute to continuous improvement of security controls and response capabilities.
This control strengthens the organisation’s resilience against security incidents and helps reduce the impact of incidents on IT services and information assets.
External reference
ISO/IEC 27001:2022 Annex A – A.5.25 Assessment and decision on information security events (Primary) A.5.26 Response to information security incidents A.5.27 Learning from information security incidents A.5.24 Information security incident management planning and preparationIS.18.002. CSIRT
Description
The UU has a Computer Security Incident Response Team (CSIRT) handling IT security related incidents
The CSIRT is mandated to respond to active threats and to take all necessary measures to limit the impact of ongoing or potential security incidents.
Technical specifications
The CSIRT mandate includes the authority to order corrective measures as part of triage.
The CSIRT has the necessary insight/experience/knowledge to handle security incidents, assess information security risks and select appropriate triage methods.
The CSIRT has an average maturity according to the SIM3 maturity model for CSIRTS of 2 or higher on each of the O, H, T and P categories (see: https://www.trusted-introducer.org/SIM3-Reference-Model.pdf
Contact information of the CSIRT is published in the RFC2350 format and kept up-to-date with the upstream CSIRT and in the trusted introducer listings at https://www.trusted-introducer.org/.
Organisation users are made aware of the CSIRT. People responsible for IT services are aware of the CSIRT and its mandate.
The CSIRT maturity is reviewed annually.
The UU CSIRT is CERT-UU, information at: https://www.uu.nl/cert
Rationale
Cyber incidents can evolve rapidly and may significantly impact IT services, data and organisational operations. Without a dedicated team responsible for coordinating incident response, the handling of security incidents may be delayed or ineffective.
A Computer Security Incident Response Team (CSIRT) provides a central organisational capability for detecting, analysing and responding to security incidents. The CSIRT is able to respond to active threats and implement appropriate measures to limit the impact of incidents.
Using recognised maturity models such as the SIM3 model enables organisations to evaluate and continuously improve the effectiveness of their incident response capabilities.
Publishing CSIRT contact information according to the RFC2350 standard also facilitates cooperation with external organisations and other CSIRTs during incident handling.
This control strengthens the organisation’s ability to manage cyber incidents and supports an effective and coordinated incident response capability.
External reference
ISO/IEC 27001:2022 Annex A – A.5.24 Information security incident management planning and preparation (Primary) A.5.26 Response to information security incidents A.5.27 Learning from information security incidentsIS.18.003. Law Enforcement
Description
There is a protocol in the event of (suspected) data-breaches when it is appropriate to involve law enforcement and through which channels. This protocol is approved by the CISO and Legal Affairs.
There is a protocol for dealing with questions from law enforcement.
Technical specifications
“Naslagwerk m.b.t. vragen van instanties”
Anton van den Hoeven, Juridische Zaken UU.
Rationale
Security incidents and data breaches may in certain circumstances have legal implications or require involvement of law enforcement authorities. Without clearly defined procedures, it may be unclear when and how such authorities should be engaged.
Establishing protocols for cooperation with law enforcement ensures that such interactions are handled in a structured and legally compliant manner. Involving legal expertise helps ensure that the organisation responds appropriately to information requests and that sensitive information is disclosed only when legally permitted.
Clear procedures also promote consistency in the handling of incidents involving external authorities and reduce the risk of inappropriate disclosure or mishandling of sensitive information.
This control supports effective cooperation with law enforcement authorities while ensuring that organisational and legal obligations are respected.
External reference
ISO/IEC 27001:2022 Annex A – A.5.28 Collection of evidence (Primary) A.5.26 Response to information security incidents A.5.31 Legal, statutory, regulatory and contractual requirementsIS.18.004. Forensics
Description
After suspected data-breaches, digital forensics are applied to targeted systems to determine the extent of the potential breach, actors, to recover data and logs and determine attack vectors.
Technical specifications
Security Operations ITS of the UU will maintain a list of trusted parties to perform digital forensics, available on request.
CERT instructs SecOps to perform research after an incident.
Rationale
Following security incidents or suspected data breaches, it is essential to determine what has occurred, which systems have been affected and what data may have been compromised. Without a structured forensic approach, critical evidence may be lost and it may become difficult to determine the root cause of an incident.
Digital forensic investigations enable organisations to securely collect and analyse logs, system artefacts and other relevant evidence. This helps determine the scope of an incident, identify attack vectors and understand the methods used by threat actors.
Forensic analysis also supports legal proceedings, cooperation with law enforcement authorities and compliance with regulatory reporting obligations.
This control strengthens the organisation’s capability to analyse security incidents and supports continuous improvement of security controls and incident response capabilities.
External reference
ISO/IEC 27001:2022 Annex A – A.5.28 Collection of evidence (Primary) A.5.26 Response to information security incidents A.5.27 Learning from information security incidentsIS.18.005. Safeguards for Incident Reporting
Description
The organization should have policies in place that allow for anonymous reporting of incidents and guarantees that reporting incidents never negatively reflects on individuals.
The official receiving party of incidents do not divulge personal identifiable information of the reporter or their named sources to parties that are not explicitly authorized to have this information.
Only if demonstrably necessary for the resolution of incidents the identity of the reporter may be shared following least privilege principle.
The identity of the reporter can be shared with specific individuals if the reporter freely consents to this information being shared to these people.
Technical specifications
Incidents and data breaches should be officially reported to CERT-UU aand the Data Protection Office (Dutch: Functionaris Gegevensbescherming). . These are the only parties that are allowed to share the PII of reporters between them without proving the need to share this information or the explicit consent of the reporter. If incidents get reported to others, they can always forward this information to CERT-UU or the DPO under the same assumptions of privacy and protection.
Rationale
An effective incident response process depends on the willingness of employees and other stakeholders to report security incidents, data breaches and suspicious events in a timely manner. When individuals fear that reporting may negatively affect them, incidents may be reported too late or not at all.
By enabling confidential and, where possible, anonymous reporting, the organisation lowers the threshold for reporting incidents. This supports earlier detection and more effective investigation and response.
Protecting the identity of reporters and any named sources also ensures careful handling of personally identifiable information and prevents unnecessary disclosure. Applying the need-to-know and least-privilege principles supports controlled and proportionate sharing of such information.
This control therefore supports both effective incident response and the protection of personal data during the reporting process.
External reference
ISO/IEC 27001:2022 Annex A – A.5.34 Privacy and protection of personally identifiable information (Primary) A.5.24 Information security incident management planning and preparation A.5.26 Response to information security incidentsIS.20.001. Certificate Management Registration
Description
Certificates for Transport Level Security (TLS) are registered with at least: for what service it was issued, what the owning group is including contact information, expiration date and technical details of certificate.
There is a process for requesting and revoking official certificates. Requesting and approving certificate requests are separate roles. The organization selects approved certificate providers..
Users receive warnings when their certificates are about to expire.
The private keys for certificates must be stored in a password vault with encryption and MFA, other than on systems where the certificates are actively used.
Technical specifications
Certificates that are visible to end-users are signed through a CA Browser forum accepted certificate authority, the certificate chain is passed along, and the certificate is valid: Deep Dive – Transportversleuteling met TLS. Selected approved certificate providers are published as DNS CAA records.
Users can request certificates on behalf of a group where they have the role of certificate requestor. Those certificates are requested with the contact information for a group for renewal notices, to avoid a single point of failure in renewal.
Wildcard certificates: only allowed as an exception under very specific circumstances: Richtlijn ‘Inzet wildcard SSL certificaten’. Certificates are always requested with parameters (hashing algorithms, private key size, validity) set according to the latest CA browser forum baseline SSL/TLS certificates https://cabforum.org/baseline-requirements-documents/
Validity of certificates is checked as part of availability checks of services.
Single domain certificates are preferred over SAN certificates.
Self-signed certificates can be used when:
The trust relation is 1-1 between applications
The certificate generation parameters used still comply to the CA browser forum baseline above
The trust is validated through an authenticated and authorized path. This path does not need to be a technical path and can be a process between people.
# Internal Link explaining digital certificates (requires SolisID);
Informatiebeveiliging – Digitale certificaten | Intranet (uu.nl)
# Public link with request procedure
https://manuals.uu.nl/nl/handleiding/ssl-certificaat-aanvragen/
Also see: IS 17.001
Rationale
Consistent certificate management ensures that all TLS-protected services rely on trustworthy, standards-compliant cryptographic credentials. Clear rules for requesting, approving, renewing, and revoking certificates reduce the risk of misconfigurations, expired certificates, or weak key material that could undermine secure communication. By defining when specific certificate types (OV, DV, wildcard, self-signed) are appropriate and enforcing baseline CA/B requirements, the organization maintains reliable authentication of services and protects data in transit. Strong key-handling practices and documented ownership further ensure that certificates remain secure throughout their lifecycle and that issues can be resolved quickly when they arise.
External reference
ISO/IEC 27001:2022 Annex A – A.8.24 Use of cryptography (Primary) A.8.20 Network security A.8.9 Configuration managementIS.20.002. Certificate Revocation
Description
If there is any indication that a system is potentially compromised, current certificates have to be revoked, new private keys generated and replacement certificates requested based on the new private keys. Clients check whether certificates have been revoked as part of the certificate verification.
Technical specifications
Private keys are not to be re-used for more than one service or identity.
Revocation procedures for the Certificate Authority have to be known and available in case of an incident.
Revoked certificates are published via the certificate revocation list (CRL), certificate status can be queried with OCSP and the certificate status is made available via OCSP stapling for public-facing services.
See also Deep dive Transportversleuteling met TLS
https://solisservices.sharepoint.com/:w:/s/10824/EWufJC7WWJVIr3eKqOBVc88BimyCynLCKAhmGa7mn5B7Mg
Rationale
he ability to revoke certificates is a critical condition for maintaining trust in encrypted communications after a security incident. When there are indications that a system or private key may be compromised, the associated certificates must be rendered invalid to prevent misuse of the established trust relationship.
Rapid revocation during an incident limits the opportunity for attackers to use compromised keys to intercept or manipulate encrypted connections. Acting quickly reduces the potential impact of a compromise and prevents prolonged exposure of sensitive communications.
By having revocation procedures available in advance and actively publishing certificate status through mechanisms such as Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP), clients are able to verify the current validity of certificates during connection establishment.
This mechanism contributes to the reliability of cryptographic protections and forms an essential part of responsible certificate lifecycle management as defined in IS.20.001 Certificate Management Registration and IS.17.001 Encrypted Connections.
External reference
ISO/IEC 27001:2022 Annex A – A.8.24 Use of cryptography (Primary) A.8.20 Network security A.5.26 Response to information security incidentsIS.20.003. Certificate Crisis Plan
Description
There is a documented procedure for dealing with situations in which mass replacement of TLS certificates is needed. The target is to return to a normal situation with valid certificates as soon as possible.
Technical specifications
This procedure describes:
• Governance
• A list of pre-approved backup certificate suppliers
• A link to the list of current certificates
• Instructions for setting priority in replacing certificates, based on impact
• Steps to replace the certficates
• Steps to ensure the certificates used in the crisis situation are managed properly
Rationale
A crisis requiring mass replacement of TLS certificates (for example due to a certificate authority vulnerability or large-scale key leakage) requires a prepared plan. Without such a plan, operational disruption may occur, recovery time may increase, and systems may unintentionally remain unavailable or accept insecure connections.
Having a pre-approved procedure with prioritised steps significantly shortens recovery time. This is more effective than making ad-hoc decisions during a crisis, which may lead to errors and delays. Pre-approved backup certificate suppliers ensure that the replacement process can continue even if the primary certificate provider is unavailable.
By documenting governance, impact-based prioritisation and a link to the current certificate inventory, a controlled and predictable crisis response can be achieved. This ensures that encrypted connections are restored to a trustworthy state as required in IS.17.001 Encrypted Connections, and that normal certificate lifecycle management as defined in IS.20.001 Certificate Management Registration can be resumed after the crisis.
External reference
ISO/IEC 27001:2022 Annex A – A.8.24 Use of cryptography (Primary) A.5.30 ICT readiness for business continuity A.5.26 Response to information security incidentsIS.4.012. Regulation of incoming network traffic
Description
Public incoming network traffic into the University of Utrecht is restricted and only permitted under specific conditions. To regulate this process effectively, network ports and services are categorized as follows:
Network Ports / Services explicitly permitted:
This category comprises communication channels that are considered to be of low risk and are therefore explicitly permitted. Examples include standard communication ports, commonly used for general online applications. Risks associated with these ports are well-understood and are mitigated through established security protocols.
Network ports / Services that may be opened upon approval:
These are less commonly used ports that faculties and departments may request permission to open. These ports have been pre-evaluated to align with the university’s risk tolerance for low-risk communication.
Prohibited network ports / Services:
All other ports and services fall under this category and are considered to be of higher risk. This includes ports used for remote access functionalities, such as terminal sessions or remote desktops. Due to the elevated risk levels associated with these ports, incoming traffic to these is strictly prohibited unless a specific exception has been granted.
Technical specifications
Technical explanation and the current list of ports in each set are maintained by Security Operations ITS and is documented in the Deep dive – Incoming network ports.