The Security Self-Assessment

The Security Self-Assessment, or SSA, is in many ways the heart of security, privacy and data protection in our products. The SSA consists of numerous requirements, recommendations and assessments for application security and privacy compliance, and is designed to provide:

  • Documentation of how the product fulfils the requirements of the SSA, and;
  • Actions that must or should be taken in order to improve security and compliance.

The SSA is a very detailed document, and is reviewed at least annually by both a member of the security team and the DPO and/ or representatives of the DPO. Having a current and reviewed SSA is also part of the VCDM approval process for products that are on the VCDM program (please refer to the introduction for an explanation of VCDM).

The output of an SSA is in the form of tickets in our development backlog system. We are a software company, and if something is not in the backlog, it does not exist. For example, if an SSA review concludes that a product should improve its encryption or client side input validation, a ticket is created and added to the development backlog. 

The ticket is then associated with the SSA in the backlog system, in order to be measured in the Maturity Indices. Important tickets, and particularly tickets associated with risk for either the customer or Visma, are further prioritised through the embedded risk management system. This enables us to measure how well we fulfil the requirements and recommendations from the SSA, and also provides us with a risk- based approach to security and privacy.

While custom-made by Visma for Visma, the SSA is, by virtue of being an application security programme, in many ways similar to industry best practices and frameworks, such as OWASP Top 10 and OpenSAMM

Here are some examples from the Visma Security Self- Assessment:

  • A system diagram, showing system components and interactions, including integrations and any external actors, such as hosting providers.
  • A list of data that is processed by the application, or which the application is designed to process. (For example, names, contacts, document types, user preference information.)
  • Data classification scheme, including categories of personal data, purposes for processing, and a rating for the data in terms of  Confidentiality, Integrity and Availability (“CIA”; a common classification triad in information security, and also found in the GDPR).
  • Standards or other requirements that may apply to the product, such as for payment services or the health and education sector.
  • Numerous requirements for Identity and Access Management (IAM), including permissions, security logging, 2- factor authentication and similar, integrations, monitoring and things like the use of encryption, secrets management and secure deployment.

In short, the SSA defines requirements and how we should meet them. How well we  actually do are measured and followed up through the use of certain tools, processes and services and then presented in the Maturity Indices.