Volg ICTI

Security Verified requirements

This ‘Security Verified’ checklist is the official description of what an organisation needs to have in order to qualify for ‘Security Verified’. It is used by ICT Institute for determining if organisations can get a ‘Security Verified’ certificate, but can be used by anyone to check their information security approach.

Version

This is the latest version, version 2021.1. You can check the previous version here: Security Verified version 2018.1. This new version has the same structure. Changes were made to include more modern control measures, make more clear what elements are needed for an effective ISMS and to improve readability.

Note: this online version contains links to relevant articles. These links are not part of the standard and these additional instructions are not required during audits. The Security Verified standard allows organisations to have their own methodology as long as it is clearly explained, observable and effective.

Overall structure

The Security Verified standard consists of two parts.

  • Part 1 (General Requirements) lists the must have elements for a functioning ISMS. An organisation must address all these elements in order to have an effective ISMS.
  • Part 2 (Example controls) is a list of recommended best practices. An organisation should evaluate these controls and implement the controls that are relevant and valuable. ICT Institute wants to see evidence of implementation for more than 50% of these controls (at least 17 out of 34).

If an ISMS meets the requirements of both parts, it qualifies for a ‘Security Reviewed’ certificate and will be included in the Security Verified register.

The structure of Security Verified is similar to ISO 27001.  ISO 27001 is a normative standard that contains mandatory elements like part 1. ISO 27002 is a collection of best practice controls, like part 2. One difference is that Security Verified has integrated GDPR compliance into part 1 since these are legal requirements in the EU.

Part 1: General requirements

Management and team

  • Top management itself has demonstrated commitment and involvement in information security.
  • A permanent security team with at least two members has been assigned. Team composition is documented in the ISMS documentation.
  • The information security team has received enough time and resources to achieve continuous improvement
  • There are at least two regular security team meetings planned, where risks, incidents and risk treatment are discussed.
  • Results and decisions from security team meetings are stored.

Security Policy Documentation

  • There is a managed set of documents stored in a central location that together form the ISMS
  • There is a main policy document that describes the scope of the ISMS
  • There is a list of stakeholders and their requirements, including legal requirements
  • There is documentation of common security-related procedures so that staff members know how to do security-related tasks correctly.
  • There is a statement of applicability that stakeholders can use to get insight into what type of measures / controls are implemented.

Assets, risks and incidents

  • The security team has created and maintains an inventory of information assets
  • The security team has created and maintains an inventory of risks, including probability and impact
  • There is a risk treatment decision for each risk, with a short treatment plan for all risks that are not accepted. Each risk has an owner.
  • There is a process for registering and handling incidents and an up to date register of incidents

Staff involvement

  • At least half the staff have attended a security awareness training
  • Future awareness trainings have been planned
  • Randomly selected staff members know whom to contact and how to respond in case of incidents or questions.
  • All staff have received security-related staff guidelines to make them aware of their role in an effective ISMS. Evidence that guidelines are received and accepted is available for at least 80% of staff.
  • There is evidence (e.g. signature) that staff have received and read the rules
  • The security team has defined actions to grow its own knowledge, e.g. through books, courses and involvement in the information security community

Privacy and Legal requirements

  • If the organisation handles personal data, there is an up to date register of processing activities
  • If the organisation handles personal data, there is a process for data processing agreements
  • There is a list of past data breaches and details on how these have been handled
  • A decision has been made and documented whether an DPO/FG is needed and who this person is.
  • On the main website, people can find a privacy statement

Part 2: Example controls

Which security measures (or ‘controls’) should be used by an organisation is different for each organisation. However there are measures that are useful for most organisations. This section contains 34 recommended controls. You must have at least 17 implemented to qualify for ‘Security Verified’. If fewer controls have been selected, we would have doubts whether a good information security policy has been implemented.

HR controls

  1. Instructions on information security are included in the onboarding process for new employees.
  2. There is a list of all company owned devices (laptops, tablets and phones) and current users
  3. There is a checklist or procedure to revoke access rights when people leave the organisation
  4. It is clear to all staff whether they can use their own devices (laptop and mobile) for company email and data
  5. It is clear to all staff whether they are allowed to work from home or other locations, and what the requirements for these locations are.
  6. There is a defined procedure for screening potential employees. For some key roles it includes a VOG / statement of conduct or calling references

Physical security controls

  1. Areas containing sensitive data and equipment are locked or otherwise have access restrictions
  2. There are rules/procedures (often called ‘clean desk’) to make sure important documents such as contracts are stored out of sight and locked
  3. There are rules/ requirements to make sure all acceptance and production servers are hosted in a secure data centre
  4. There is a separate wireless guest network; clients and visitors do not have access to the employee wireless network
  5. There is no printer or if there is one, there is shredder or locked recycling container. If the printer is on a different floor, a PIN code must be entered at the printer

Device security and system access

  1. PCs and laptops have an up to date OS, a firewall and antivirus software
  2. Devices (PC laptop, tablet and smartphone) are encrypted and protected with password or biometrics
  3. Employees get a unique new email address and access to assets is linked to this email address
  4. There is a policy and training that requires people to choose strong and fresh passwords
  5. Multi-factor authentication is enabled for employees to access company email or main systems

Technical security controls for systems

  1. Communication to and from all servers is secured using https, SSL or other secure protocols. A score is available using internet.nl, SSL labs or similar tool
  2. Documented information is available on the OS, programming language and frameworks used, and only supported versions are used in production
  3. Production servers produce logs. This information is stored securely and log reports / data can be shown by the information security team
  4. The production servers are monitored to measure uptime, resource limits or performance issues. The team can show the monitoring dashboard or an SLA report.

Secure software development and acquisition

  1. For main systems there are separate acceptance and production environments (optionally also development and test).
  2. All software developers or suppliers have working knowledge of secure software development (e.g. OWASP) through training or contractual agreement.
  3. Source code is stored in a central version management system so that changes can be tracked over time.
  4. No production data or anonimized production data is used in acceptance environment
  5. External ethical hackers are regularly (recurring PEN-test) or continuously (bug bounty program) invited to test security. A PEN-test report less than 1 years old is available
  6. There is a project plan template / procedure that includes security and privacy measures and it has been used for a specific project

Backup and business continuity

  1. A backup and restore procedure for servers is documented including the backup frequency. Production servers are backed up at least daily. The procedure (both backup and restore) is tested periodically.
  2. There is a backup plan for office documents. The result must be that all office documents that users work on are either stored in the cloud or backed up on a daily basis
  3. There is a business continuity plan with at least 4 scenarios and instructions for each scenario.
  4. There is a report from a business continuity test/exercise that has been performed

Recurring controls

  1. There is an overview of all suppliers, information security requirements for each supplier and a score for each supplier on the service in past period
  2. There is a procedure for internal security audits, requested by management executed outside the information security team.
  3. There is an overview (e.g. calendar, plan, roadmap) for the next 12 months with recurring security activities
  4. A regular management review is planned where top management reviews and approves the ISMS