End users are actively informed on the organisational policies regarding acceptable use of assets. Organisationally offered IT assets and services must be used for professional purposes, the usage of free/private alternatives is not allowed. Templates & References Example AUP (NL): GebruiksreglementDownload

The Information Systems and Processes are identified and registered. Each System and Process has an owner within the organisation. The owner is responsible for compliance with the organisational information security policy. Ownership falls to a single person and not to an organisational unit. Systems and Processes are classified according to the organisational classification policy to determine the appropriate level of protection. The classification is reviewed and updated periodically. The owner is responsible for the classification.

Organisations maintain an accurate and up-to-date registry of organisational hardware and software assets in a Configuration Management Database (CMDB).

The assets making up a system that are under control of the organisation are registered and tracked in the CMDB. System owners periodically check that the information in the CMDB regarding their systems is accurate and up-to-date. System owners accurately maintain any documentation needed to deliver, describe, support and maintain the systems.

Description Organisations actively and passively detect assets that may not be registered in the CMDB, both within the network and outside. Discrepancies in CMDB and detected assets are resolved.

Available patches and/or security fixes are installed in compliance with set and approved policies (including those for operating systems, databases and installed applications) and recommendations of CERT and/or suppliers.

Emergency changes requiring immediate implementation are properly handled to ensure minimal impact on systems and IT applications. The emergency change is registered, evaluated and tested after implementation and approved by responsible management.

Description Planned changes are evaluated for potential security impact. The classification of all processes and systems involved in the change is reviewed and adjusted where necessary. In projects, sufficient resources including time, manpower and budget are allocated to perform a security assessment and ensure compliance with the information security policy

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 parties.

The organisation must know what software is used on managed devices, including a Software “Bill-of-Materials” (BOM) of libraries and components.

Before engaging in an agreement with a supplier of an IT-service, an information security risk assessment is performed. Contractual agreements regarding information security are made with suppliers of IT-services. Suppliers report on their compliance with these agreements and will deliver evidence of compliance when prompted. This compliance is actively monitored by the organisation and documented. Non-compliances are treated as potential security incidents. Which suppliers the organisation has, what services they provide and the status of contracts with the supplier are documented.

For every system a documented backup procedure is available with values for the RPO (Recovery Point Objective, maximum tolerable amount of data that can be lost) and RTO (Recovery Time Objective, maximum downtime of the system). The RPO and RTO are communicated to users of the system. The backup procedure will identify the appropriate: type(s) of storage media used for backups, frequency, reduncancy, storage location, storage conditions and frequency of restore testing. How data on endpoints is backed up is included in the backup procedure. Backups are tested periodically to verify that they can be restored. The results of these...

Data centres used in the processing of information take appropriate measures to guarantee continued uptime.

All critical backup media, documentation and other IT resources needed for IT recovery, and business continuity plans are stored offsite. The content of backup storage is determined after collaboration between business process owners and IT personnel. Management at the offsite storage facility acts on the basis of data classification policy and the enterprise’s media storage practices. IT management ensures that offsite arrangements are periodically assessed, at least annually, for content, environmental protection and security. Compatibility of hardware and software for restoring archived data is ensured, and archived data is periodically tested and refreshed.

All data in transit is transferred over encrypted connections, using the encrypted versions of protocols or encapsulation of plaintext protocols over encrypted connections.

Automatic forwarding of email to external addresses is denied-by-default.

IT components send emails to end-users using an email address ending in a top-level domain for which the organisation is legally responsible. 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.

Communication coming from outside the organisation needs to be clearly distinguishable from internal communication with warnings that the originating party is from outside the organisation. This includes electronic messages received in email programs.

The organisation has processes for IT incidents in place. IT incidents are evaluated if they are potential security incidents. (Potential) Security incidents are treated according to a documented and standardised procedure. This procedure differentiates based on the risk involved and includes appropriate escalation, risk treatment steps, evaluating the relationship to other reports/alarms and root-cause analysis. Security Incidents are evaluated (either aggregated or individually, based on the severity) and appropriate measures are taken to prevent future occurances of the incidents. Information on security incidents is handled on a need-to-know basis. Security incidents involving Personally Identifiable Information (PII) are also considered a...

A disaster recovery plan (DRP) exists for potential disaster scenarios that could affect the IT systems. The disaster recovery plan is reviewed at least annually. The disaster recovery plan is tested periodically.

A business contuinity plan (BCP) exists for potential disaster scenario’s that could affect the critical processes. The business contuinity plan is reviewed at least annually. The business continuity plan is tested periodically.

The organization has a (contracted) CSIRT. The CSIRT is fully mandated to respond to active threats to limit the impact of potential security incidents.

After incidents, the organisation communicates openly and truthfully to affected parties/subjects, without creating additional security risks to the organisation itself. After (potential) major incidents, the evaluation and lessons learnt will be shared within the industry to improve cyber resilience of the entire sector.

Data at rest is always stored encrypted. The organisation is responsible for the key management of the chosen encryption solution, either directly, contractually or through policies.

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 organisation selects approved certificate providers. Self-signed certificates are never allowed. If there is any indication that a system may be compromised, current certificates are revoked, new private keys generated and replacement certificates requested based on the new private key. Clients check whether certificates have been revoked as part of...

The proces owner authorises distribution of confidential information explicitly to any recipient, internal or external to the organisation. For all non-incidental data transfers, the authorisation is documented and reviewed yearly. The authorisation includes which data can be shared, which persons/systems are authorised and under what conditions. 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.

Description It is possible for organisational data to be deleted from devices remotely by a device management system, if they actively make a connection or based on an interval without any connection. Encrypted data to which the keys are made unrecoverable complies with this standard.

Only data owners have access to their data. Administrators and suppliers can only access the data through a break-glass procedure that involves business sign-off and consultation with the organisation.

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.

Printing services are appropriately protected: Printers are kept separate from the public internet. Printing requires authentication before printing. No repeating printing statements. Documents are stored encrypted and for as short a time as possible. Print jobs only start after user authenticates at the printer.

After the retention period or when the data medium is decommissioned, lost or repurposed, organisation data is deleted. End users receive sufficient warning before data is deleted.

The rules regarding the processing of data are made explicit and clear, including whether remote work is allowed, under what circumstances and the use of Bring-Your-Own-Device and how data storage should be handled (including paper media, USB devices, retention of the data in mail clients, how data can be exchanged with other parties, etc…)

How long data is retained and available is identified and recorded and adheres to the minimum legal or business requirements. After this period, data is deleted and unrecoverable. This includes sensitive data stored on hardcopy which needs to be properly shredded and destroyed.

Unless necessary for executing job responsibilities, by default user endpoints do not allow the execution of scripts and executables. If the function necessitates this access, it will be documented and approved by the supervisor.

Preventive, detective and corrective measures are in place (especially up-to-date security patches and virus control) across the organisation to protect information systems and technology from malware (e.g., viruses, worms, spyware, spam).

Regular end-users do not have privileged access to endpoints continuously, including but not limited to the ability to modify organisationally managed system settings, changes to environment variables, directly modify the registry, modify files in system directories or install programs. 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 just-enough admin. These privileges are registered together with the reason why and the approver.

Endpoints have appropriate protections to prevent attacks on memory.

When a workstation is left unattended, the session/screen is locked automatically after a maximum of 15 minutes and the user prompted for re-authentication.

Shared workspace endpoints are physically protected from tampering with or removing the hardware.

Manuals and Operating Procedures that detail how to work with Information Systems and Services in a secure manner are available and communicated to end-users. Understanding of the operating procedures is verified and adhering to these procedures is monitored. Appropriate measures are taken when operating procedures are not followed.

Before commencement of processing activities all individuals working with data and systems have been identified using a nationally issued Identification Document or through a trusted federated identity provider.

Before commencement of processing activities background checks are performed for all individuals working with sensitive data and systems to determine integrity and suitability for the tasks and ensure secure behaviour. Screening is repeated periodically and a procedure is in place to deal with situations where screening identifies security risks.

Non-contracted visitors in sensitive areas are always accompanied by organisational staff.

The organisation has a policy for disciplinary action and inappropriate handling of information. 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 Organisational Unit, CISO and HR that will determine the disciplinary action.

When working with sensitive information, individuals are required to agree with and sign a non-disclosure agreement (NDA). At a minimum the NDA specifies how the individual should handle the sensitive information and how long restrictions apply after working with the information has ceased. Also, the NDA specifies the consequences for the individual when breaching the agreement.

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. 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...

The organisation has a coherent awareness program that identifies the knowledge relevant to information security various stakeholders must have, the ways to measure the current level of knowledge, and includes planning and organisation of interventions to maintain and increase the knowledge to desired levels.

End-user authentication for applications takes place through a trusted Identity Provider for anyone with access to organisational data. 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 the production IdP.

After a period of 45 days of inactivity or at the end date of a formal relation with the organisation for which the account was provided, accounts are automatically blocked. After 90 days the account is deleted or stripped of all authorisations. Unblocking accounts follows the same approval process for requesting access as Joiner/Mover situations.

System owners define how user management takes place, including who is authorised to request changes to which user roles and how this can be requested/managed. System owners determine the access control models used for which types of users.

Periodically, a list of all users in the system is generated along with associated permissions and reviewed. If it is available, all access rights must be in accordance with the authorisation matrix. A documented procedure is available for how the review is performed. Actions taken based on the review are recorded and stored for 2 years. If the authorisations are given based on role, the authorisations within the roles are part of the review as well.

Systems that allow setting passwords enforce that passwords satisfy minimum complexity requirements. Rate-limiting is enforced for failed password entries. 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 are 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.

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 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 NIST Special Publication 800-63 section 5.2.3: https://pages.nist.gov/800-63-3/sp800-63-3.html#sec5....

Passwords must by default not be visible during entry (only when prompted by the user as a usability feature). Passwords are not visible in any other way (including to administrators) and are not stored in a way that can be reversed. If passwords/secrets are stored, they must be stored in an appropriate password vault service.

Users must 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 maximum period 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...

After a period of inactivity in an application, the user session should be locked and require re-authentication. Activity in another application from the same identity provider may be considered continued activity.

Once issued, a digital account/identifier is connected uniquely with a natural person. Once issued, (old) accounts and unique account information are never (re)assigned to other natural persons. After individuals have left the organisation, their digital & legal identities are kept for a predefined period of time, based on business and legal requirements.

Individuals receive only the minimum number of authorisations required for their role and purpose in the processing activities. Authorisations are only given for the period the activities take place. Preferably these are given based on a role and not attached to individuals.

Process approve users getting authorisations to the data in the process. The requests of individuals that want access to information assets or authorisations to do so, are logged and retained 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 retained for at least 1 year. 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. If...

Process owners are responsible for an authorization matrix listing who has what access to data and functionality in relevant systems, in what capacity. The authorisation matrix includes roles, the authorisations in roles, individuals and which roles the individuals are allowed to have. Optionally, job functions can be used to identify which roles belong to those functions. If there conflicts between certain authorisations that cannot be given simultaneously, the authorisation matrix identifies which combinations of authorisations are not allowed. Template-AutorisatiematrixDownload

Creation of new accounts with privileged authorisations, mutations in user groups through which privileged authorisations can be obtained and changes in passwords for non-personal privileged accounts are approved Potential abuse cases for the (attempted) use of privileged authorisations are defined and monitoring impemented for these cases. False positive situations are approved by the System Owner before being allowed.

At least every month for all current accounts the number of lock-outs, current account status, account end-date and account-deletion date (if relevant) is reported.

Protections are in place to detect and prevent unauthorised user activity based on context and behaviour.

Description Events potentially relevant to the security of systems are logged in a central logging system (different from the originating system) with timestamps synchronised to official timeservers in UTC. Logs are protected from modification. Logs are reviewed periodically.

Applications log access (attempts) to sensitive data. Applications log mutations of system configurations and sensitive data. Original values are recommended but not necessitated to be stored.

Authentication attempts are logged including originating IP and attempted user. Passwords are not logged. Access to the network is logged.

Event data is aggregated from multiple sources. Accepted organisational risks are monitored through defined abuse cases. Personnel security and awareness is monitored and periodically tested.

There is security monitoring on organisational credentials appearing in (publicized) data-breaches. If there are indications of compromise of passwords, or risks that the credentials of individuals are compromised, passwords will be forcibly changed and the users informed.

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 and block traffic until it has been established if the traffic does not pose unwanted risks.

Network Access Control is used to determine the level of access users are given to the internal network. Unidentified users get access to the guest network. The authentication system shall be tied to the hardware asset inventory data to ensure only authorised devices can connect to the network. Authenticated users with managed devices can be allowed on the internal network pending verification by a client program of the device OS security update level and anti-malware status. Filters are in place against spoofed addresses.

Identify known malicious domains, IPs or other content and block access to these sources from the organisational network, systems and managed devices. Enable Domain Name System (DNS) query logging to detect hostname lookups for known malicious domains.

Networking maintains a list of approved hardware components and their required configurations. Networking hardware components are not accessible to unauthorised individuals.

Networks are segmented if they serve different business purposes or have differing risk levels, determined by the classification of the assets in the same segment. Each network segment is separated by a (virtual) Firewall. Best practices for Network Naming Security are followed. Managed systems belong to one organisationally managed security domain.

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 authorisation.

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 deny all traffic that is not explicitly allowed by default. Rules that allow traffic necessary for functionality follow 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...

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 DDoS attacks for example). A procedure is in place to throttle traffic from non-critical sources, to ensure continued minimal essential functioning of the service.

Access to physical areas housing IT equipment or sensitive data must be logged and checked at least monthly for deviating situations. Procedures for working in secure areas are in place and adherence to them 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.

Emergency power to IT equipment is available or a hot-site connected to a separate power source is available.

A distinction must be made between security levels within the IT landscape when considering privileged access secret authentication information, where a logical distinction is made at least for user endpoints, network access-layer, network core, server-administrator and domain administrator.

Administrative interfaces (other than application-level) are only accessible from an internal zone designated for administrative tasks. Access to this zone is secured via jumpservers. These jumpservers are used exclusively for the privileged actions.

Privileged Access involves all user access that exposes more functionality than regular users have on any layer of the IT service infrastructure. Authorisations for privileged access are required to follow 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 authorised personnel, an authorisation matrix is available for this access. Templates and references Template-AutorisatiematrixDownload

Service accounts are only used when necessary for system authentication (no association with natural persons) or system-to-system authentication. The purpose of a service account is always 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 accounts can only be used to automate tasks for the individual user and not for generic processes. Changes to service accounts are...

Accounts for privileged users are separate from regular user accounts. If a user needs privileged functionality, a second (privileged) account will be created to keep the privileged and non-privileged activities separated. Privileged Accounts usage is Just-in-Time, meaning they are only provided when needed and the access revoked after the tasks are completed. Logging in with privileged accounts on public facing services is prohibited, only local services (with non-internet routable IP’s) may be configured to accept direct logins with privileged accounts. There are additional protections to change or reset MFA access methods for Privileged Access, that involve validating the identity of...

Privileged Access to IT services is orchestrated through a Privileged Access Management (PAM) 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.

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 non-privileged). Passwords are rotated after use of Break Glass Procedure The CISO and Process Owners are informed of any use of the break-glass procedure.

Authentication for access using privileged accounts includes Multi-Factor Authentication. This can include Multi-Factor Authentication to get access to a network and subsequent strong cryptographic asymmetric keys for authentication. Devices cannot be marked as ‘trusted’ for Multi-Factor for privileged access. MFA-tokens used as factors are user-specific and measures are in place to safeguard that these tokens remain strictly personal.

Description At a minimum there are distinct environments for acceptance and production. Where development activities take place, at least one separate environment for development exists. The environments are clearly distinguishable (for example through a different colour scheme). Privileged Access to the production infrastructure is completely separated from privileged access to the other environments. Authentication to non-production environments does not take place through the production IdP. The acceptance environment must represent the production environment as closely as possible with the exception of not being publicly available. Before going into production, any change must always be tested in the acceptance environment.

No production information is exposed or reused in environments other than for acceptance testing. This includes production data (also not pseudonymised), API keys, credentials and production server hostnames.

Major changes and/or migrations that could have potential impact on the availability of the IT service have a rollback procedure and a step-by-step plan for the change documented beforehand and approved by the relevant change boards. This rollback procedure can be requested.

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, 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 is stored in environment variables or in versioned scripts that generate the configuration based on user input.

All variable information that gets sent by a client is filtered and sanitized before being processed in the application. The same applies to user-selected output that is presented back to users. This avoids any unintentional side-effect of processed data.

Web applications have taken all appropriate measure to protect against OWASP top 10 Web Application vulnerabilities: https://owasp.org/www-project-top-ten/

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 containerised. Sensitive information must be stored server-side unless specifically needed for functioning of the application.

The application has taken application level steps to prevent Denial of Service attacks such as caching where possible, 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.

The system scans attachments, uploads and links for malware and filters content identified as harmful by these scans.

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.

Document a security configuration baseline for the system based on current best practices from vendors and desired functionality. The baseline must be updated at least annually. Use this baseline for all new and recovered systems.

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. Systems are periodically checked against the hardening baseline, preferably automatically.

Applications and services are configured to not display information that is unnecessary. Functionality is designed and configured to prevent enumeration of information.

Default Passwords on any piece of hardware or software are changed before deployment.

Services run under their own account with minimal necessary privileges . Only necessary services run on production servers, and are only accessible to necessary interfaces using Host-based Firewalls. All services are maintained and kept up-to-date. For each running service on servers, hardening guides are followed and deviations from hardening guides due to business requirements are documented.Local Firewall rules limit service traffic to ports filtered as restrictive as possible.

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.

A system owner is responsible for maintaining a list of known vulnerabilities on the system, including the associated risk, when the vulnerability was reported, what action resolution was taken and the current status of the vulnerability. Vulnerabilities can be ‘resolved’, ’mitigated’ or ‘accepted’. If the vulnerability is ‘mitigated’, a new risk estimation needs to be done for the mitigating measures in place. After resolution, resolved vulnerabilities need to remain registered for 1 year. The organisation shall establish maximum resolution time of vulnerabilities based on the associated risk. There is monitoring on the timely resolution of vulnerabilities.

The organization has a published Coordinated Vulnerability Disclosure Policy to encourage security researchers and individuals to ethically find and report vulnerabilities.

Network connected IT systems are subjected to automatic vulnerability scanning at least once per month. Scanning occurs authenticated where possible.

The (web-)application is subject to automated vulnerability scanning at least once per quarter. Scanning occurs authenticated as much as possible.

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 security party. For externally performed pentests, organisational security staff assesses the management summaries of a recent pentest results and the follow-up to findings.The management summary contains at least which party performed the test, when the test was performed, what the scope of the test was, the number of vulnerabilities that were found and their associated risks. The re-test results are also inspected.

Applications that communicate to end-users do so from an organisational domain and organisational email account.