SWEDAC DOC 10:5
PDF-format MD Markdown-format
Publicerad:
2026-09-16
Utgåva:
5

Guide for information security work

2.1 Purpose

The purpose of this document is to provide accredited bodies and bodies seeking accreditation with guidance on improving information security. The document also provides guidance on information security assessment requirements.

The checklist at the end of the document can be used for internal and external audits.

2.2 Scope

The document applies to all types of computer systems and support systems used in the accredited bodies, both direct production systems and support systems for the management system. Examples of such systems with different names in brackets;

2.3 Identification and functionality of input systems

Requirement reference:

As a starting point for the work on information security, the organisation should identify which systems are used, the functionality of each system and the functional connections between the systems.

A reconciliation should then be made with the accreditation standard to see if there are requirements in it that relate to the functionality of the system such as response reporting, document management, measurement of quality indicators, approval of documents, traceability to which changes have been made in results. The starting point is that the requirements for data functions are in line with those for manual paper-based procedures.

The data in the system should be evaluated in order to establish what is a valid original and what copies (electronic and paper) and what handling procedures apply to the latter.

All the staff concerned must have the necessary access to instructions and information for the execution of the work. The operational requirements for system availability and the fallback procedures must therefore be documented.

2.4 Linkage between systems

Requirement reference:

All parties to the exchange of information should understand and have documented the potential risks associated with the exchange.

Accredited bodies have a primary responsibility for validating the entire exchange initially and in case of changes occurring in the transmission chain.

The recipient of the information is responsible for carrying out plausibility checks to stop gross misstatements.

2.5 Organisation

Requirement reference:

The data systems of an establishment are subject to equivalent requirements as for other accredited bodies with regard to the competence, competencies, responsibilities and powers of the staff.

The requirements also apply to services and products that the accredited body receives or purchases from both external and internal suppliers. The accredited body is always responsible for ensuring the quality of the services/products purchased through contracts and controls.

For systems that communicate with other systems, both within their own operations and with external ones, cooperation between the different parties responsible for development and operational support should take place with a clearly documented division of responsibility. The allocation of responsibilities should also cover the updating of system descriptions and common procedures.

All users of a system should have received adequate training in the management of the system, as well as procedures and rules for both normal and abnormal operational situations.

The training should be documented and linked to the certificates of competency issued in the management system

The operational support resources should be of sound technical competence, follow quality assurance procedures and be organisationally located at a level commensurate with the use made of the system.

There should be documentation of the decision-making process when dealing with errors or when a new system version is to be commissioned. Competence to become operational or to take decisions on the continued operation of the system despite faults detected, possibly with control measures, should be linked to operational and IT competence. At times when regular data personnel are not available, decision-making personnel should have sufficient competence to assess the consequences of observed data errors and take the necessary measures.

2.6 Documentation, system description

Requirement reference:

System description includes documentation of functionality, system platforms and technical solutions necessary for system maintenance and further development. Relevant documentation including the supplier’s manual for the management and maintenance of the computer system should be available to the relevant staff.

The system description may consist of external documents from the supplier supplemented with descriptions of local customisations and communication with other systems. All documents must be document controlled and there must be traceability to which version of the system the description refers.

If the system is unique and owned by the accredited body, it must be ensured that in all future situations a complete copy of the documentation is available to ensure the system’s survival.

2.7 Maintenance procedures

Requirement reference:

Accredited bodies should have documented procedures for:

2.8 Change procedures

Requirement reference:

The system shall be validated for proper functioning, availability, traceability, transparency and access by unauthorised persons. Validation should be carried out for any system changes in the system platform or application software.

The purpose of validation is to ensure the quality of a system or the exchange of information between systems.

This can be done in different ways or in combination:

Validation should follow a documented procedure covering the entire data flow. The procedure should describe the method of validation in case of changes and ensure that supporting documentation is created. The supporting documentation should include a summary report detailing the reason for the validation, who performed the validation and the time, system version, results and decision. The results should be supported by evidence.

If the accredited body rely on external validation of system changes, the reports of the external validation should be sufficiently detailed to allow for proper decisions to be taken.

When introducing a new computer system or in the event of major changes, the accredited body must contact SWEDAC for planning assessment work.

2.9 Archiving

Requirement reference:

The archiving requirements of the management system for data in the system must be defined and met. For data stored on a particular system, such as in a previous operating system, a plan must be in place on how the activity intends to ensure the continuity of the computer system during the retention period.

2.10 Risk management

Requirement reference:

The system must meet basic requirements for security and confidentiality in respect of the authorisation and control systems (BKS), protection against computer viruses and backup.

If the system uses underlying access protection in the operating system, database or word processor to protect the integrity of the data, this must not be able to be circumvented. Supplier’s requirements for operating systems and settings must be followed.

The basis for modern information security work is to conduct a documented process analysis of the information flow of the business. As part of the process analysis, the performance of risk analysis includes an assessment of risks related to the accuracy, availability, transparency and traceability of the information. The risks found are evaluated against the management system’s policy with requirements for the organisation’s information security.

Process analysis of information security can usefully be done with a comprehensive view in connection with process analysis of ordinary bodies.

2.11 Acquisition of new system and development of own system

Requirement reference:

Software development should follow the guidelines of international standards. If the supplier is certified according to an international standard, this can be an advantage, otherwise the business should take note of the supplier’s routines, such as validation of software, request for changes and correction of found errors.

When developing systems, the work should be quality assured through documented procedures and instructions. Risks should be identified in terms of technical and competency vulnerability. Source code rights and responsibilities for specifications, testing and operations should be clarified.

2.12 Checklist for internal and external audits of data operations

Activity:
Date:
Responsible IT:
Participants:

Items that are not relevant to the current system are marked as not applicable at the time of the audit.

1. Identification and functionality of input systems

2. Organisation

3. Contracts

Agreements with all parties outside the business (suppliers, customers, group IT department) covering

Applicable when information is exchanged with other systems, e.g. electronic responses, web access to reports.

4. Documentation, system description

System documentation indicates

5. Maintenance Procedures

6. Change procedures

7. Archiving

8. Risk management

9. Procurement of new systems and in-house development