---
id: SWEDAC DOC 10:5
titel: Guide for information security work
beskrivning: The document provides accredited bodies and bodies seeking accreditation with guidance on improving information security and describes the requirements applied in the assessment of information security.
publicerad: 2026-09-16
utgava: 5
pdf_url: swedac-doc-10-5_en.pdf
sprakkod: en
---

# 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;

- LIS (LIMS, lab computer system, production system)
- Lab Module (POCT, PNA)
- Booking (RIS etc.)
- Order and response
- Image processing (PACS)
- Physiological analysis systems
- Document Management
- Issue, deviation, complaint handling
- Internal Audit Management
- Permission Management (driver's licence)
- Spreadsheet and word processor macros
- Programmable Table Calculators
- Process control (control system, tracks)
- Instrument systems (embedded computers, workstations to instruments)
- External support systems and web services (sampling instructions, population registration, QC)

## 2.3 Identification and functionality of input systems

**Requirement reference:**

- ISO/IEC 17025; 8.1.1, 8.3
- ISO/IEC 17020; 8.2.1, 8.2.2, 8.2.5, 8.3.1
- ISO/IEC 17021; 10.3.1, 10.3.3
- ISO/IEC 17065; 8.2.1, 8.2.2, 8.2.5, 8.3.1
- ISO/IEC 17024; 4.4
- ISO 15189; 7.6, 7.8, 8.1.1, 8.3
- ISO 20387; 7.10.1, 7.10.3

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:**

- ISO/IEC 17025; 7.11.6, 7.11.2
- ISO/IEC 17020, 6.2.13
- ISO/IEC 17021; 10.3.3
- ISO/IEC 17065; 4.5
- ISO/IEC 17024; 4.4.1, 4.4.3
- ISO 15189; 7.6.3
- ISO 20387; 7.4.7, 7.5.1, 7.10.3

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:**

- ISO/IEC 17025; 6.2, 6.6.2, 7.10.1
- ISO/IEC 17020; 5.2.7, 6.1.1, 6.1.4, 6.1.5, 6.1.10, 6.2.14, 7.1.8
- ISO/IEC 17021; 6.1, 7.1, 7.2, 7.5, 9.1.3, 9.2.2
- ISO/IEC 17065; 5.1, 6.1, 6.2, 7.3, 7.4.2
- ISO/IEC 17024; 4.2.4
- ISO 15189; 5.2.2, 6.2, 6.8, 7.5, 7.6
- ISO 20387; 6.2, 6.4, 7.10.3

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:**

- ISO/IEC 17025; 8.3.1
- ISO/IEC 17020; 8.2.4
- ISO/IEC 17021; 10.3.3
- ISO/IEC 17065; 8.2.4
- ISO/IEC 17024; 4.2, 4.6
- ISO 15189; 7.6.3, 8.3
- ISO 20387; 4.1.4, 7.10.3, 8.3

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:**

- ISO/IEC 17025; 7.11, 6.4
- ISO/IEC 17020; 6.2.5, 6.2.13
- ISO/IEC 17021; 10.3.3
- ISO/IEC 17065; 8.3
- ISO/IEC 17024; 4.4
- ISO 15189; 6.4, 7.6
- ISO 20387; 6.5, 7.10.3

Accredited bodies should have documented procedures for:

- preventive maintenance and monitoring of system functionality.
- situations when the system is not working as intended. The fallback procedures shall include regular work instructions, as well as troubleshooting, error reporting and remediation. Changes, errors and actions should be recorded on paper or electronically

## 2.8 Change procedures

**Requirement reference:**

- ISO/IEC 17025; 7.11
- ISO/IEC 17020, 6.2.13
- ISO/IEC 17021; 10.3.3
- ISO/IEC 17065; 8.3
- ISO/IEC 17024; 4.4
- ISO 15189; 7.6
- ISO 20387; 6.5, 7.9, 7.10.3

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:

- Testing (testing) in a specific test environment or operating environment
- Parallel execution of new system/new version against an existing system/version
- Control of results against orders, manual worklists, raw data, manual calculations or alternative response methods not covered by the change.
- Comparison of data in the respective systems in case of electronic transmission between systems
- Periodic sample testing on systems in operation to ensure that there has been no change, for example, in configuration parameters, vendor patches or in the external communication chain.

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:**

- ISO/IEC 17025; 8.4
- ISO/IEC 17020; 7.3, 7.4, 8.4.1,
- ISO/IEC 17021; 10.3.4
- ISO/IEC 17065; 8.4.1
- ISO/IEC 17024; 4.6.2
- ISO 15189; 8.4
- ISO 20387; 4.1.8, 7.10.6, 8.4

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:**

- ISO/IEC 17025; 7.11, 8.5
- ISO/IEC 17020, 6.2.13, 8.8.1
- ISO/IEC 17021; 10.3.3
- ISO/IEC 17065; 8.8.1
- ISO/IEC 17024; 4.6.1
- ISO 15189; 5.6, 7.6.3, 8.5
- ISO 20387; 4.2, 4.3, 7.10.3, 8.5

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:**

- ISO/IEC 17025; 7.11
- ISO/IEC 17020, 6.2.13, 7.1.8
- ISO/IEC 17021;10.3.3
- ISO/IEC 17065; 8.3
- ISO/IEC 17024; 4.4.3
- ISO 15189; 7.6.3
- ISO 20387; 6.4, 6.5, 7.9, 7.10.2-7.10.3

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

- System Name:
- Version:
- Vendor:
- System Platform:
- Computer:
- O/S:
- dbms:
- Development Tools:
- Functionality:
- Connection to other systems:

### 2. Organisation

- Is the operating aid organisation described in the management system (e.g. in the form of different roles as system owner, system manager, system operator)?
- Is placement shown in organisation chart?
- Are there deputies for all functions?
- Does the management system or contract specify the liability of external suppliers?
- Is it clear that the operation holds primary responsibility for validating the entire transfer chain when transferring between systems?
- Has the operational support organisation of the system received sufficient and documented training?
- Is the authorisation system (licence) also used for the management of the computer system?
- Is there documentation of training and information about the computer system?
- Are internal quality audits of data operations carried out regularly?
- Do the purchasing procedures in the management system also cover computer equipment and services?

### 3. Contracts

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

- critical hardware and software support
- connections and transfers to external systems (web, EDI, email)
- Are all parties clearly described – including subcontractors and third party suppliers?
- Is there a requirement to have a contract with any third party, e.g. service for equipment not owned by the business, sub-contractors for programme development, operating support at EDI?
- Are the responsibilities/limits and commitments of the different parties in normal management described (who does what, when and how)?
- Is the agreed functionality specified?
- Is the agreed availability of access to/receipt of information specified?
- Is ownership and responsibility for the information stated?
- Are contact persons listed?
- Are the names and privileges of persons who carry out work on the premises of the establishment or have access to the computer system of the establishment indicated?
- Are responsible for updating agreements, system descriptions and common documents listed?
- Is a skills guarantee given?
- Is there a commitment to comply with documented security and privacy rules and that access/access to the systems is not possible for anyone other than competent staff?
- Is there a commitment to record key system events and error actions in the Event Viewer or Case Management System?
- Is a description of the fallback procedures for different types of errors available?
- Are reporting times specified for operating aid (also in the case of new developments)?
- Is Trouble Ticket Availability and Contact Routes Specified?

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

- Are agreed protocols and platforms for transfers between systems described?
- Is a description of each party's monitoring of information exchange available?
- Is there a commitment to provide information on events and changes that may affect the exchange of information?
- Are plausibility checks which the recipient undertakes to make to stop gross errors, such as data not being sent twice, being transmitted incompletely or incorrectly, described?
- Is there a commitment to inform the parties concerned without delay of any suspected errors in the exchange of information?
- Is it specified who is responsible for troubleshooting different parts of the chain for transmission failures between systems?
- Is there a commitment to verify that information is exchanged correctly following changes in codes, functions, platforms and that the intersystem transfer bodies have a primary responsibility for the validation of the entire chain?

### 4. Documentation, system description

- Is a system description available?
- Which internal and external documents are included?
- Are all document controlled and traceable to the current system version? Is there a list?
- Is the documentation sufficient for operational support and development.
- If the system is unique, does the business have access to a copy of the detailed documentation in the event of a disaster?

**System documentation indicates**

- the functions of the computer system. If a standard system is in place, it shall be documented which functions, if any, are not used.
- a description - preferably graphic - over
  - Hardware
  - system software
  - network
  - connections to external systems
  - information flow
  - database structure
- login protection/access
  - virus protection
  - transparency (e.g. firewalls, secure network, encryption, or non-sensitive information)
- communication with external systems
- transfer formats and mappings
  - how the information is protected against changes e.g. by checksum calculation, encryption or traceability by matching logs with content before and after processing
  - logs that information has been transmitted and what has been transmitted during despatch, receipt and retransmission.
  - how the sender can view sent messages, recovered or saved.
  - Log monitoring capabilities. Archiving times.
  - Receipt functions and notifications for information exchange
- Is there a user manual (or built-in help system)
- Is the user manual document controlled?
- Is traceability available for which system version the instruction applies to?

### 5. Maintenance Procedures

- Is there a documented procedure for preventive inspection, maintenance and monitoring of:
  - hardware
  - disk capacity
  - backup
  - correct data transfer between systems
  - reporting procedures (email, paper)
- Is all IT equipment individually marked and listed in a register (document or maintenance database)?
- Are there logbooks (or documents/maintenance or case management systems) for IT equipment such as:
  - server
  - PC
  - printer
  - network equipment
  - software systems
  - electronic data transfer
- Is the logbook system described in the management system?
- Are the logbooks used?
- Can the equipment be identified?
- Are the entries dated and signed?
- Are corrective actions recorded?
- Can the current version in use be identified in the system or through documentation?
- Are there maintenance procedures for code sets used in information transfer?
- Are responsibilities and authorities for maintenance of code sets documented in the management system?
- Is there a written procedure for all relevant personnel (including any external suppliers) to follow in case of different types of system errors? The procedure shall include:
  - the organisation's handling of total system downtime (contingency routines, system recovery)
  - the organisation's handling of various error situations, such as network interruptions, PC failures, printer errors, software faults, transfer errors to another system, email transfer errors
  - how error reporting and correction shall be carried out from personnel via IT
  - who is responsible, possibly including suppliers
  - how errors and corrective actions shall be documented
  - who is responsible for following up errors reported to the supplier
  - who is responsible for troubleshooting different parts of the chain in case of transfer errors to another system
  - in the event of serious software errors, such as mixing of results – actions to ensure quality, e.g. extra verification of report printouts
- Is the procedure available, known, and up to date?
- Are authorities to implement actions in the event of identified errors documented in the management system (e.g. to put the system in/out of operation, correct errors/order corrections, implement quality control of results)?

### 6. Change procedures

- Is the system versioned? (Does version management also include peripheral parts of the system such as response reports, file conversions, instrument interfaces.)
- Is the build-up of version management documented?
- Indicates the version designation in technical documents, test reports, manuals, error reports.
- Is final validation against locked (frozen) versions of the system?
- Is there a documented procedure for checking reports against basic material? Is this
  - for all answers routinely
  - at start-up
  - in the case of a serious defect.
- Is there a dedicated test environment?
  - is it documented?
  - is there a risk that the test environment is used inadvertently or that the test response will be sent to the customer?
- Does the business have access to detailed reports from the supplier's testing?
- Is there a written validation procedure in which it is clear when the validation/verification is to take place, e.g. at
  - new system version
  - minor changes/fixes in programme code
  - upgrade hardware or system software (server and clients, browser)
  - new instrument
  - new version of software in instruments
  - changes to connected external systems or part of the communication chain
  - new or modified analysis/survey including code works changes
  - change in calculation functions
  - new customer or changed customer information such as address/reporting method
  - new or changed format electronic ordering or electronic report (message or web)
  - new response report
- who is responsible for sufficient testing, who is competent to carry out testing, who approves the test carried out and who takes the decision to put into service
- instructions on how to carry out the test. Level of detail sufficient to cover all normal variation and extreme cases and to provide uniform testing even if several persons test. Expected result so that the test can be repeated.
- How the testing shall be documented. Instructions or a predefined template for documentation shall include:
  - who performed the testing
  - when the testing was conducted
  - the reason for the testing
  - whether the validation was carried out in a test or production environment
  - version of the tested program/system version
  - reference to any detected errors
  - which supporting documentation (printouts, screenshots) shall be retrieved from the system to verify the testing
  - how different markings in the documentation indicate that information has been verified and is correct/incorrect – e.g. by using a line or a check mark next to the verified item
  - summary of results, decision on commissioning

### 7. Archiving

- Is the computer system used solely as an archive for certain data? What archiving times are stated in the management system. Is it described how you intend to secure the archive, etc., platform and skills?

### 8. Risk management

- Available written backup routine that covers:
  - rotation scheme description
  - media labelling
  - responsible (and deputy)
  - management
  - storage of daily backup and system backup for unique software in other fire zone, fire resistant cabinet
  - that completed backup and any errors are noted in the logbook
- Checks made backup by eg. re-reading?
- Is there a documented procedure for re-creation?
- Are the responsibilities and powers for the operation and management of the backup system documented in the management system
- Does the system of authorisation provide adequate protection?
  - Is the rating system documented?
  - How often does a password change?
  - How many characters is minimum?
  - Can passwords be reused?
- Do visitors have access to equipment? Is it possible for unauthorised persons to read on monitors?
- Is regular or continuous anti-virus screening of PC.
- Is anti-virus protection documented?
- How is proper transmission between systems ensured? Are checksums and unique sequence numbers used in message transfer? Is there receipt handling?
- Check premises for.
  - heat and humidity
  - fire, flood protection
  - dust
  - electricity supply
  - sources of interference
  - lock access protection?
- Control of manual result input and change of results. Matches issued permissions?
- Control of traceability of a sample: Signoffs, times, changes, link to control sample?
- Checking of time limits. Same time on server and all clients?
- Documented risk analysis available
- Covers all use cases such as
  - Communication terminal<->server, client<->server, server<->server
  - Communication with external systems e.g. EDI web reports, web ordering, population register
- Are information assets classified
- There are overall information security policies and guidelines
- Is the risk assessment made for deficiencies in the information
  - accuracy
  - accessibility
  - transparency
  - traceability
- Is there an agreed action plan that includes planned measures, bodies, times, responsibilities
- An action plan for post-disaster recovery
- Are there spare equipment or an action plan for non-critical equipment?

### 9. Procurement of new systems and in-house development

- An international standard is used as the basis.
- Is there a clearly defined customer-supplier relationship? (Also in the case of internal development)
- Are agreed specifications used to clarify the function for all involved parties?
- What is the approval process for specifications and delivered functionality?
- Is there an agreement on how changes and additions to the original specification should be managed?
- Is there an agreement regarding acceptance testing?
- Is there an agreement regarding acceptance review of documentation?
- Are source code rights clarified and specified in the agreement?
- Has an analysis of risks and vulnerabilities been conducted – both technical and competence-related?
- Is testing carried out according to plans? Does the supplier document their testing?
- Are there defined design rules for naming conventions, commenting, etc.?
- Are there risks associated with the chosen development tools? Have these been identified and agreed upon?
- Are manuals updated after changes?
- Is planning done with baseline plans and follow-up/revision? Are plans coordinated between customer and supplier?
- Are there agreements with external developers covering access rights, authorities, competence requirements, source code rights, and service commitments?
- Is there a formalised method or routine that covers the most common types of further development?
- Does it cover all stages of the development chain?
  - Preparation of specifications
  - Design
  - Coding
  - Testing
  - Validation/verification (see item 6)
  - Documentation including user manuals
  - Information
  - Commissioning
  - Correction of any errors
  - Changes and additions to the original specification
  - Updating of documentation following program changes