UKOLN logo NOF-digitise
Technical Advisory Service
2001 - 2004 archive
nof logo AHDS logo

Compliance Corner

Compliance corner comprises a series of issues that have arisen in the context of projects meeting technical standards. This page covers:

Security Standards

It is noted in the Technical Standards and Guidelines on security that your project should be managed in accordance with the Information Security Management guidelines laid out in BS7799: Part 1.We recognise that compliance with BS 7799 part 1 is by no means a trivial undertaking and may in many instances be inappropriate to the security needs of your website. However it is nonetheless important that your site complies with certain minimum recommendations. Becta states:
"Although compliance with BS 7799 part 1 is not a "Must" requirement, projects "must" adhere to the following:

  • The machines used to deliver projects must be operated in as secure a manner as possible
  • The advice in operating system manuals concerning security must be followed
  • All known security patches must be applied

If a project is not aiming for BS7799 part 1 compliance, they should return in either their Section A or Section B report details of the security arrangements that they will be implementing. These arrangements will need to provide reassurance that the site is being delivered in as secure manner as possible - for instance the project should:

  • ensure arrangements are in place for the timely application of any security patches
  • confirm that the server(s) and any associated computers have been correctly configured to provide the optimum level of security
  • confirm that a schedule of timely data backups is in place
  • confirm its network is protected by a firewall with all unnecessary ports closed
  • describe the physical security of the project's server(s)
  • provide details of the people in the organisation who have administrator rights to its machines

Part of the process of achieving compliance with regard to security is the careful documentation of both the security measures you have set up and the ongoing process of maintaining those security measures. For example, with regard to security patches, it is important to keep a watch on announcements of new security patch releases and apply them immediately; the latter is important since they sometimes appear in response to a perceived and imminent threat. Thereafter it is vital that you document the version and release date of the patch applied and the date when applied. Such records build into documentary evidence of your project's timely and effective implementation of your security measures.

Should your site be externally hosted then it is important to provide the reassurances noted above by quoting the relevant sections of your service level agreement with the organisation that is hosting your site.

Data Protection Act

Note also the "Must" requirements in Technical Standards section 3.1.4 Security that relate to personal information:
" The management and use of any personal information must conform to the Data Protection Act 1998."
This means that if your project is collecting personal information, such as the personal details of users, emails, etc., you must confirm that management of such information is carried out in accordance with the Data Protection Act 1998.

Protection of Data Subjects' Email Details: A common pitfall

Where projects may, with users' consent, hold data on a body of people, termed data subjects, care must be taken in the use of such data, particularly when contacting data subjects. It should be noted that even a person's email address constitutes personal data and a project has a duty of care with regard to the disclosure of a person's email address, even where the latter is freely transmitted to the project.

A common pitfall for projects and other organisations is the unwitting disclosure of email addresses among the data subjects of a project. In other words, persons who were previously unaware of the email address of other users of the site are able to read and use the address. How does this happen?

Origin of the Problem
In seeking to contact the website's users, projects frequently use a groupname in the to: or c.c. line of their mail client. The use of groupname will include all the addresses of persons entered into the mail address groupname and so avoid the need to send individual emails to possibly hundreds of people. Alternatively on other occasions, the list of email addresses is entered in the c.c. line en masse.

The Problem
Herein lies the pitfall: whether a groupname or a long list is entered in either the to: or c.c. line of the email to be transmitted, when sent, that email will expose the email addresses of all the other persons included in the mail header to all its recipients. This arguably constitutes a breach of the rules about disclosure. The data subjects have not expected their email address to be passed round to many other persons. It will only take one of the persons to misuse the email address by contacting the disclosed person for, say, commercial purposes, for the accidental disclosure to cause annoyance.

The Solution
While the use of b.c.c., blind carbon copy, is not possible with all email clients, some, such as Microsoft systems, permit the addition of an extra mail header called b.c.c. A simple way therefore to mail all recipients without disclosing any address other than your own and the individual recipient's is by placing all addresses to be contacted in the b.c.c. line.

In so doing it should be remembered that the text of the email message needs to be phrased in such a way as to reflect the diverse audience. The message equally should be written in a way that does not accidentally disclose information improperly.

On reception the email recipients will see at most your address, their own address and no other. In this way, no accidental disclosure of personal data occurs.

Further Reading

Technical Standards: 3.1.4.Security

British Standards Institute
This site will permit you to search for the relevant standard but full access does involve the payment of a not insignificant sum.

What is BS 7799?
A commercial site offering some FAQs and a questionnaire on usefulness of BS7799 to your project.

Data Protection Act 1998

The Principles of Data Protection

Anyone processing personal data must comply with the eight enforceable principles of good practice. Personal data covers both facts and opinions about the individual. It also includes information regarding the intentions of the data controller towards the individual, although in some limited circumstances exemptions will apply. With processing, the definition is far wider than before. For example, it incorporates the concepts of 'obtaining', holding' and 'disclosing'.

The fuller explanation of the 8 principles is also available:

The Data Protection Act: A brief guide for data controllers then 'Compliance Advice' then 'Data controllers brief guide'.

It is vital that those who collect and use personal data maintain the confidence of those who are asked to provide it by complying with the requirements of the Data Protection Act.

The World Wide Web Security FAQ
This is a site maintained by volunteers and hosted by W3C as a service to the Web Community; (however, it does not endorse its contents). It attempts to answer some of the most frequently asked questions relating to the security implications of running a Web server and using Web browsers.


Return to Compliance Corner contents

UKOLN is funded by MLA, the Museums, Libraries and Archives Council, the Joint Information Systems Committee (JISC) of the Higher and Further Education Funding Councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

T A S : 2 0 0 1 - 2 0 0 4 : A R C H I V E
This page is part of the NOF-digi technical support pages
The Web site is no longer maintained and is hosted as an archive by UKOLN.
Page last updated on Monday, May 09, 2005