Scaleable Database Controls for Part 11 Compliance

A good question posted on-line in the 21CFRPart 11 Yahoo Group, going to the heart of security controls around Electronic Records

Q Consider an electronic record system utlizing a typical database where a User ID and Password combination are used as an electronic signature to sign the records.  Assume the front end application has sufficient controls to prevent manipulation of the signature by the users.

Without getting too technical, what types of controls and solutions have you folks seen in terms of ensuring compliance with the requirements of 11.70 in regards to access to the database on the back end, typically by a DBA? 

How do you ensure that the linkage from record to signature is secure enough in the database to prevent manipulation by the DBA via ordinary means (i.e. with standard functionality and tools)?

Is there a risk justification for allowing the DBA some ability to manipulate the signature linkage, or should it be prevented by all but extraordinary means (i.e. using non-sanctioned tools, hacking, etc.)?

A. Without getting too technical there are a variety of controls that can be used. Which is implemented depends on risk and should be decided based upon the outcome of a documented risk assessment.

The first step is to use digital rather than electronic signatures. At its simplest, this means calculating some sort of 'hash' (fancy checksum) which is calculated using the contents of both the record and signature components. If either the record or signature components are changed, any attempt to recalculate the hash will come up with a different answer and you will the know that something has changed.

It won't however tell you what was changed - for that you need to rely on audit trails which can be set up at either the applications level (looking at changes to the defined record) or at the database level, to identify any inadvertent or accidental changes at the database level.

There is still the chance that the DBA can turn off the audit trails, so with some databases (e.g. Oracle) you have a couple of other options. The first is to write the audit trails into a separate database schema to which the DBA does not have access. This can use something like Audit Vault technology, which means the audit trails are written to a separate database server. The second is to make the database tables 'virtual private' database tables, which means the DBA can't even see them, let alone access them.

There may be circumstances when the DBA needs to access the database to make changes at the data level e.g. data corruption, or an accidental deletion by a user. It is permissible to make corrections under these circumstances, but you need a strict change control procedure to record what is being fixed, why and when (i.e. to preserve the audit trail). In such circumstances you would typically issue the DBA with a 'Super DBA' user account and password to make the changes, and then change the password afterwards (obviously someone needs to be trusted at some point).

One important principle is the idea of 'motivation' - why would a DBA want to make such changes? Organisational controls should be in place (including training and sanctions) to prevent e.g. a DBA and a system user from working in collusion to falsify records. Clearly system users should not also be DBAs.

It is therefore possible to make your Part 11 records and signatures very, very secure, but the more secure they are the more complex and expensive the solution. That's where the risk assessment is important - to identfy what is appropriate for any given set of records.