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 2018.08. You can check the previous version here: Security Verified version 2016.10. This new version has the same structure. Changes were made to include GPDR compliance, and to improve overall readability.

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 14 out of 28).

If an ISMS meets the requirements of both parts, it qualifies for a ‘Security Reviewed’ certificate.

The structure of Security Verified is similar to ISO 27001 / ISO 27002.  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 is a schedule of regular meetings that ensure the continuous working of the ISMS.
    There is evidence (e.g. meeting minutes) that show to topics discussed and decisions made for past meetings.

Security Policy Documentation

  • There is a main policy document that describes the scope of the ISMS and it contains or lists available documentation.
  • The policy documentation describes stakeholders and their requirements, including legal requirements
  • The policy includes information security goals and also concrete metrics that can be used to measure ISMS effectiveness
  • There is documentation of common security-related procedures so that staff know how to do security-related tasks correctly.
  • There is a statement of applicability or a similar document 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.
  • There is a risk treatment decision for each risk, with a short treatment plan for all risks that are not accepted. Risk treatment plan is regularly reviewed and approved by management or risk owners.
  • There is at least one regular meeting for maintaining the assets, risks and treatment plan.
  • 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.
  • 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 and a clear person responsible for making sure all business partners that get personal data sign a data processing agreement.
  • There is a process for determining whether a DPIA is needed and to conduct a DPIA when needed.
  • There is a contact person for staff to report incidents. There is a documented procedure for analysing incidents and handling data breaches.
  • 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 contact information for making a GDPR request.

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 28 recommended controls. You must have at least 14 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. A check is made when people leave the company whether assets are returned. To do this, documentation on who has which asset is maintained
  3. It is clear to all staff whether they can use their own devices (laptop and mobile) for company email and data
  4. 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.
  5. There is a defined procedure for screening potential employees. For some key roles it includes a VOG check 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 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 professionally, e.g. in a secure data center.
  4. There is a secured wireless guest network; clients and visitors do not have access to the employee wireless network

System access controls

  1. There are rules that make the use of passwords mandatory where possible and forbids the use of standard passwords.
  2. For all major systems, users have individual accounts. There are no shared accounts in use by multiple people.
  3. For systems designed by the organisation, the use of strong passwords is mandatory using a built in check
  4. Multi-factor authentication is in use for system access (either at infra level or for key applications).

Technical security controls for systems

  1. Communication to and from all servers is secured using https, SSL or other secure protocols
  2. All production servers have a firewall installed
  3. All production servers produce logs. This information is stored securely and monitored for important events using alerts or daily checks

Technical security for devices

  1. PCs and laptops have a firewall enabled and antivirus software installed
  2. Devices (PC laptop, tablet and smartphone) have an up to date, still supported OS version.
  3. There is a backup or recovery plan for when devices go missing or are stolen. Possible elements include encryption, wiping and disabling accounts
  4. Data on mobile devices is encrypted

Secure software development and acquisition

  1. All software developers or suppliers have working knowledge of secure software development (e.g. OWASP) through training or contractual agreement.
  2. There is an internal test/acceptance checklist that includes some security checks before changes are pushed to production.
  3. External ethical hackers are regularly (recurring PEN-test) or continuously (bug bounty program) invited to test security

Backup and recovery plan

  1. For main systems there are separate acceptance and production environments (optionally also development and test).
  2. A backup and restore procedure is defined. Production servers are backed up at least daily. The procedure is tested periodically.
  3. 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

Recurring controls

  1. The information security team has planned regular meetings open to all staff with updated information on security
  2. There is a procedure for internal security audits, requested by management executed outside the information security team.