Documenting decisions

Explanations should always be internally documented for any access status other than open. This is to ensure other members of the team can understand the original logic for any given access status and to ensure they can easily find the data in question when re-reviewing material.

Sensitivity reassessments or any other changes to the access status undertaken after initial cataloguing should also be documented.

Bear in mind that team members may have limited knowledge of any wider context and may be looking at the catalogue record several years, if not decades, after the access status was determined.

Cataloguing Systems and Fields

CALM

Decisions and explanations should be documented in the Sensitivity_Description field using the format specified below.

Sensitivity_Assessment_Date should also be used to record the date a sensitivity assessment took place, if the assessment occurred outside the primary cataloguing process, or when reviewing digitised material.

Sierra

Decisions and explanations should be documented in the 901field in the bib record.

|a records the assessment (in the format specified below)

|d records the date that decision was made.

The date of the assessment is added the end of the field. It is only required if the assessment occurred outside the primary cataloguing process, or when reviewing digitised material.

---

Rules

• When undertaking a sensitivity review use the following format:

Not sensitive/Sensitive/Sensitivity expired. Reason: [free text following guidance below]

• Include one of the following statements if the item is being reassessed at a later point:

  • Reassessed as part of annual January openings

  • Reassessed by Access Advisory Panel

  • Reassessed as part of a targeted collection/series/item re-review.

• Be specific and provide enough information to allow other members of the team to understand the original logic for the decision made.

• If reasoning is particularly complex or lengthy it may be appropriate to record the details in a document save it in the applicable Collection File on the SharePoint. In this instance, the existence and location of such a file should be noted.

• Do not use personal names in the explanation. If necessary, use initials.

• You are not required to add “Not sensitive” to records deemed open at the point of cataloguing. This should only be done if material looks like it might be sensitive and it is appropriate to clarify why it is open (see example 3 below).

• An explanation on how the expiry date was derived can be included if it is not clear.

• When a reassessment has occurred, retain the original sensitivity reason at the end of the statement, but update "Sensitive" to "Sensitivity expired" (see example 4 below).

• For born-digital records, include details of any large batches of files that could not be sensitivity reviewed due to being inaccessible (i.e. lacking correct software).

• When undertaking a sensitivity review as part of digitisation use the standard phrases set out in Assessment tracking document AND include the phrase ‘Reassessed as part of a targeted collection re-review’.

Content examples

1. Sensitive. Reason: Includes full names and blood groups

2. Sensitive. Reason: Includes successful and unsuccessful candidates and information about a named individual's application

3. Not sensitive. Reason: individuals are sufficiently anonymised

4. Sensitivity expired. Reassessed as part of annual January openings. Contains full names.

5. Sensitive. Reason: named individual gives detailed description of childbirth experience. Reassessed as part of a targeted collection re-review.

6. Unavailable online. Sensitive. Reason: Includes references. Reassessed as part of a targeted collection re-review.

Sierra coding examples

901##Sensitive. Reason: contains patient name and medical diagnosis. Reassessed as part of a targeted collections re-review|d18/07/2023

901##Available online. Not sensitive. Open with Advisory. Reason: Animal dissection. Graphic.|d10/06/2021