SharePoint Configuration Guidance for 21 CFR Part 11 ...download.microsoft.com/download/9/A/A/9AA9CACF-B... · SharePoint Configuration Guidance for 21 CFR Part 11 Compliance

SharePoint Configuration Guidance for 21 CFR Part 11 Compliance

Published: April 2012

Microsoft Corporation

Health and Life Sciences Industry Unit

Paragon Solutions

Health and Life Sciences Practice

SharePoint Configuration Guidance for 21 CFR Part 11 Compliance

Introduction .................................................................................................................................................................................................... 1

Acknowledgements ........................................................................................................................................... 2

Architectural Approaches to Compliance ................................................................................................ 3

Use Cases for 21 CFR Part 11 Compliance ............................................................................................... 4

Electronic Signature Use Cases .......................................................................................................................................................... 4

Digital Signatures Use Cases ............................................................................................................................................................... 6

Architecture for 21 CFR Part 11 Compliance .......................................................................................... 8

Windows Server 2008 R2 ...................................................................................................................................................................... 8

Active Directory Domain Services ..................................................................................................................................................... 8

Active Directory Rights Management Server ............................................................................................................................... 8

Active Directory Certificate Services ................................................................................................................................................ 9

Active Directory Federation Services ............................................................................................................................................ 10

SQL Server 2008 R2.............................................................................................................................................................................. 10

SharePoint Designer ............................................................................................................................................................................ 10

SharePoint 2010 Architecture for Compliance ......................................................................................................................... 10

Database Security ................................................................................................................................................................................. 11

Configuring the Electronic Signature Use Cases ................................................................................ 12

Administrator Configuration for Single Signatures ................................................................................................................ 12

Digital Signatures Use Case ........................................................................................................................ 47

Administrator Configuration for Digital Signatures ............................................................................................................... 47

21 CFR Part 11 Requirements ..................................................................................................................... 56

Subpart B Electronic Records ..................................................................................................................... 57

11.10 Controls for Closed Systems ................................................................................................................................................ 57

11.30 Controls for Open Systems .................................................................................................................................................. 64

11.50 Signature Manifestations ...................................................................................................................................................... 65

11.70 Signature/Record Linking ..................................................................................................................................................... 65

Subpart C Electronic Signatures ................................................................................................................ 66

11.100 General Requirements ......................................................................................................................................................... 66

11.200 Electronic Signature Components and Controls ...................................................................................................... 67

11.300 Controls for Identification Codes/Passwords ............................................................................................................. 67

Systems Validation and Compliance ....................................................................................................... 70

1 SharePoint Configuration Guidance for 21 CFR Part 11 Compliance

Introduction Since the release of the Microsoft Office SharePoint Server 2007, compliance has

been a major focus of the Microsoft Office System. That focus continues with

SharePoint 2010 and includes additional functionality that further enhances

compliance capabilities.

In addition to the audit trails and document level security that were introduced in

SharePoint 2007, there are now enhanced capabilities for document and records

compliance. These enhanced features include:

Records center document libraries can be placed anywhere in a site collection

In-place records management in any document library

Centrally managed and distributed content types and taxonomies

Centrally managed policies and workflow enforced on content types

Workflow can promote a document from loose collaboration to a formally

declared and managed record , including the capability for electronic

signatures.

Multi-stage records disposition

Centralized audit trails and audit trail reporting that is easily configured with no

additional coding necessary.

While these features can be applied to a broad range of regulations, including

Sarbanes-Oxley and HIPAA, they also apply to 21 CFR Part 11. Thus the Microsoft

Office SharePoint Server 2010 when combined with other Microsoft technologies,

including Active Directory, Information Rights Management, and (optionally) the

Microsoft PKI system, provides a system that may be configured to assist with 21 CFR

Part 11 compliance.

In a departure from previous whitepapers on the topic, we approach this document a

bit of a different way:

1. Describe the overall SharePoint architecture needed to support compliance.

2. Including both conceptual and product-level architectures.

3. Provide a set of use cases for compliance and then detail the configurations

necessary to support those use cases.

4. Provide a mapping between 21 CFR Part 11 and the configurations detailed

as part of the use cases that support each individual line of the regulation.

This approach will be more useful for those involved in the validation effort as it

provides the use cases and then the configurations necessary for validation.

Of course, software cannot be compliant by itself, so SharePoint 2010 and other

Microsoft technologies must be used in conjunction with a broader compliance

framework, including appropriate configurations, policies, procedures and validation

documentation that are the responsibility of the implementing party.


Acknowledgements

As with any effort of this size, there are a myriad of persons involved in its development. In this case, the

efforts of Paragon Solutions (http://www.consultparagon.com) in the development of the demonstration

system, SharePoint configurations, workflows, SharePoint Designer configurations and sample source code,

all of which were absolutely essential for this project to be successful.

It is also necessary to acknowledge the Life Sciences Industry Unit members who wrote and reviewed the

configuration text, the use cases, regulation interpretation and guided the development of the end product.

Finally, it is necessary to acknowledge the efforts of the Microsoft Consulting Services on the 2007 version of

this whitepaper, portions of which remain intact especially in the section that maps each part of 21 CFR Part

11 to the needed configuration step.

http://www.consultparagon.com/


Architectural Approaches to

Compliance When considering regulatory compliance, whether it be for eDiscovery, Part 11, DDMAC, SOX, or any other

regulation, the most important step in the process is planning the architecture. While the SharePoint system

is eminently flexible, that flexibility can also pose challenges down the road if you take a wholly haphazard

approach. A good plan, consistently applied, will take you far and avoid pitfalls.

When building the plan it is important, first and foremost, to understand the overall capabilities of the

platform. In this case, it is important to understand that SharePoint has a plethora of capabilities in the

Enterprise Content Management (ECM) space.

Equally matched by the capabilities Foundational ECM capabilities in SharePoint are the plethora of partners

that embrace and extend the SharePoint platform. These include vendors that provide out-of-the-box Part

11 and GxP compliance, vendors that provide capabilities for scientists through electronic lab notebooks and

LIMS systems, even vendors that provide manufacturing and plant floor monitoring capabilities – all on

SharePoint. These are in addition to the workloads listed in the graphic above.

For the purposes of Part 11 compliance, we will be looking at the features that Microsoft categorizes as

Records Management . For planning Records Management systems, the implementer will need to factor in a

couple key considerations:

Policies & Workflow

File & Archival Plan – In-Place Records vs. Centrally Archived

Managed Metadata and the Taxonomy Term Store

Managed Metadata and the Taxonomy Term Store provide more flexibility to the end user as well as the

system administrator when it comes to Metadata. Users are no longer simply consigned to setting the

metadata through dialog boxes at upload time, but can actually set the metadata for a document during the

authoring process. Similarly, content managers have the ability to manage the metadata, through

hierarchical means, and propagate those terms throughout a site collection.

Supplemental ECM

Embrace and Extend Workloads with Partners

Physical Records

Management

Business Process

Management

Transactional

Content

Management

Scanning and

Capture

Archiving and

Library Services

Industry Specific

Solutions

Foundational ECM

Document

Management

Records

Management

Web Content

Management

Rich Media

Managment

Document

Output

Human Centric

Workflow

E-Mail

Archiving*


The decision whether to use in-place records or centrally archived records becomes crucial when configuring

the system for Part 11 compliance. In this document, the workflows and configurations demonstrate both

approaches, by using in-place records for most electronic and digital signature workflows, but then using a

central archive record store once a document’s lifecycle has run its course.

Policies and workflow are central to configuring SharePoint 2010 for compliance with any regulation. In this

whitepaper we will discuss at length the use of workflow for electronic and digital signatures, as well as the

use of policies to determine which documents need signatures.

Given those key considerations, the balance of this document will be split into two parts:

1. A discussion of configuring SharePoint 2010 for Part 11 compliance

a. Utilize a Use Case methodology so the document can be used providing guidance for

your own validation efforts

b. Provide the architecture to support the Use Cases

c. Detail the workflow and policies for electronic signatures

d. Detail the workflow and policies for digital signatures

e. The promotion of records to in-place and centrally managed records

2. Mapping 21 CFR Part 11 to the areas of the previous use case to demonstrate how SharePoint

meets those regulations

Use Cases for 21 CFR Part 11

Compliance In this section we will detail common use cases that require 21 CFR Part 11 compliance and then will step

through the configuration of the system for that use case.

There is another use case allowed for in Part 11, namely Biometric based signatures. While the combination

of Windows 7, Active Directory and hardware manufacturers provide for this capability which can be

extended to SharePoint, it is so uncommon a method of authentication and signature that it won’t be dealt

with in this context.

Electronic Signature Use Cases

The following use cases will detail the configurations and resulting process for applying an electronic

signature to a document either in a single signature scenario or in a multiple signature scenario.

Single Signature Use Case

To support the use case where the process requires a single electronic signature per document the site

administrator will:

Configure document library templates for electronic signatures

o Update the document library with new columns

o Set the Content Approval Status

o Set the Document Version History settings

o Create and add document templates for embedded signatures (optional)


Create workflows for Electronic Signatures

o Utilize SharePoint Designer

o Attach the workflow to the document library

Set the policies for the document template

o Create custom security for the content-type

o Set permissions on the content-type so that regulated documents cannot have the version

history changed or versioned documents modified

Create a customized page that captures the username and password for the electronic signature

o Twelve lines of source code (provided) are used to call the LDAP store to authenticate the

signature before storing it with the record.

o The source code for authentication is added to the SharePoint Designer page created for

the signature workflow.

Note: This system details use of an optional embedding of the signature into the Word Document, providing

a visible record in the document itself of the signature process.

The user will:

Navigate from the their project page to the document management library for that project

View the documents currently in process and the workflow status of each document

Author the document to make necessary changes

Save the document to the library

Submit the document for workflow approval

Sign the document as part of the approval workflow

View the audit trail (workflow history) of the document library

Multiple Signature Use Case

To support the use case where the process requires multiple electronic signatures per document the site

administrator will:

Configure document library templates for electronic signatures



o Set the Document Version History settings which turns on audit trails.

o Create and add document templates for embedded signatures (optional)

Create workflows for Electronic Signatures






history changed or versioned documents modified


Create a customized page that captures the username and password for the electronic signature

o Twelve lines of source code (provided) are used to call the LDAP store to authenticate the

signature before storing it with the record.

o The source code for authentication is added to the SharePoint Designer page created for

the signature workflow.

Note: This system details use of an optional embedding of the signature into the Word Document, providing

a visible record in the document itself of the signature process.

Each signing user will:






Sign the document as part of the approval workflow


Digital Signatures Use Cases

The following use cases will detail the configurations and resulting process for applying a digital signature to

a document either in a single signature scenario or in a multiple signature scenario.

Single Signature Use Case

To support the use case where the process requires a single digital signature per document the site

administrator will:

Configure document library templates for digital signatures

o Update the document library with appropriate columns for workflow



o Create and add document templates for digital signatures

Create workflows for Digital Signatures

o Utilize SharePoint Designer (if designed)





history changed

These configurations will enable the user to:







Sign the document in Office 2010 client

Save the document to the document library as part of the workflow


Multiple Signature Use Case

To support the use case where the process requires a single digital signature per document the site

administrator will:

Configure document library templates for digital signatures




o Create and add document templates for embedded signatures

Create workflows for Digital Signatures






history changed

The user will:






Sign the document in Office 2010 client

Save the document to the library as part of the workflow


User Authentication Use Case

Security and access control are central concepts for compliance. With the new reality of cross-company

collaboration, authentication control is even more important.

However this is also more straightforward, as there are clear instructions in other Microsoft documents on

the use of Active Directory and Active Directory Federation Services with the use of SharePoint that a

discussion here is not necessary.


Architecture for 21 CFR Part 11

Compliance Given the use cases detailed above, there are a few key architectural components that are required in order

to provide 21 CFR Part 11 compliance. As we detail each of these architectural components we will see how

Microsoft technologies, when used together can provide compliance with many different regulations, but

only as configured and implemented in the end-user's system and in the context of the implementers

requirements.

Windows Server 2008 R2

Windows Server is the basis for all the components needed for regulatory compliance. Some of the key

compliance features of Windows Server 2008 R2:

The ability to provide detailed IQ reports when used with a software distribution system such as

Microsoft Systems Center Configuration Manager

The ability to provide detailed OQ reports when used with the systems management provided

through Microsoft Systems Center Operations Manager.

The ability to provide Network Access Protection which enforces health requirements by monitoring

and assessing the toll of client computers when they attempt to connect or communicate on a

network. Client computers that are not in compliance with the health policy can be provided

restricted network access until their configuration is updated and brought into compliance with

policy.

The concept of server roles allows server administrators to quickly and easily configure any

Windows-based server to run a specific set of tasks and remove extraneous 0S code from system

overhead. Windows Server 2008 R2 further extends this model would support work more rules in a

broadening of current role support. The Server Core installation option is important to mention

here as it only includes necessary components for running applications such as SharePoint.

Active Directory Domain Services

Part of Windows Server 2008 R2 Core Infrastructure is Active Directory Domain Services. While SharePoint

can utilize an LDAP system, Active Directory provides the means to manage the identities and relationships

that make up your organization's network in a way that is easily integrated with the rest of your Microsoft-

based infrastructure. It gives out-of-the-box functionality needed to centrally configure and administer

system, user, and application settings.

Active Directory Rights Management Server

The next component in the identity and access management system is Active Directory Rights Management

Services (AD RMS). With AD RMS you can augment and organizations security strategy by protecting

information through a persistent usage policies, which remain with the information, no matter where it is

moved. You can use AD RMS to help prevent sensitive information such as clinical trial reports, site

monitoring documentation or even e-mails from intentionally or accidentally getting into the wrong hands.

In SharePoint 2010 this is configured through the Information Rights Management (IRM) screen which can

be applied at the document library or document library template level.


It is important to note that users do not have to have Office installed to read protected documents and

messages. SharePoint 2010 with Web Applications understands rights management, so any user with access

to a browser and rights to the document can view the document.

It is also important to note that users do not need to reside within your organization, as long as they are

granted appropriate rights. Any user with a Hotmail account or a LiveID can be granted access to a

document and then able to view it through a SkyDrive account or through e-mail.

Active Directory Certificate Services

Active Directory Certificate Services provides customizable services for issuing and managing certificates

used in software security systems employing public key technologies. Active directory certificate services cast

that allows organizations to deploy a digital certificate infrastructure, creating a Web of authentication

between devices, users, and applications.

AD CD is a role in Windows Server, which provides an integrated public key infrastructure (PKI) that enables

capabilities such as digital signatures, strong authentication, and secure communications.

These certificates when used in conjunction with Office 2010 provide the ability to sign Microsoft Office

documents which are compliant with the XML-DSign and XAdES standards for digital signatures. Since

XAdES forms the basis of other standards such as Safe BioPharma, this system can be integrated into a SAFE-

compliant system in a fairly straightforward manner.

What is XAdES?

XAdES (XML Advanced Electronic Signatures) is a set of tiered extensions to XML-DSig, the levels of which

build upon the previous to provide more and more reliable digital signatures.

By implementing XAdES, Office complies with the European Union Advanced Electronic Signature Criteria in

Directive 1999/93/EC as well as a new Brazilian government directive which defines XAdES as the accepted

standard for digital signing in Brazil.

Office 2010 can create different levels of XAdES signatures on top of XML-DSig signatures:


Time Stamping and XAdES-T Signatures

Time stamping digital signatures (XAdES-T signatures) is an important scenario we focused on in Office

2010. In order to create a time stamped signature, you’ll need to:

Set up a timestamp server that complies with RFC 3161.

Configure signature policy to let the client systems know where to locate the timestamp server.

You’ll also need to add the timestamp server’s root certificate to the root certificate store.

Once everything is configured, you can just create signatures like you normally would. A timestamp from a

trusted timestamp server extends the life of your signature, because even after the certificate expires, the

timestamp proves that the certificate had not expired at the time of signing. As a result, time stamping

protects against certificate expiration, and if the certificate was revoked after the signature was applied, the

signature is still valid.

Active Directory Federation Services

While not a hard and fast requirement for Part 11 compliance, ADFS provides simplified access and single

sign-on for on premises and cloud-based applications in the enterprise, across organizations, and on the

web. In the case of access to compliant SharePoint sites, it allows IT administrators and end users to grant

access to known entities, even users outside their organizational boundaries.

ADFS and SharePoint together accomplish this by using SAML 2.0 standard claims-based authentication and

security. Once the ADFS servers of two organizations are “pointed” at each other through a simple

configuration, end users from both organizations are free to collaborate, participate in workflow and even

execute electronic or digital signatures in both organizations SharePoint sites.

SQL Server 2008 R2

Microsoft SQL Server 2008 R2 is a complete set of enterprise ready technologies and tools that provide the

database and business intelligence technologies for SharePoint and many of the other Microsoft platforms.

As a database management platform, SQL Server 2008 R2 manages databases more efficiently and

effectively. It provides your people with built-in tools for greater control and oversight. It manages at scale,

automate automates tasks, and streamlines troubleshooting.

As the business intelligence platform, it is a comprehensive platform for business intelligence that includes

enhanced reporting, deeper and more powerful analysis, rich data modeling, master data management

capabilities, and full integration with Microsoft Office.

Microsoft SQL Server 2008 R2 also provides the database and business intelligence platform for SharePoint

2010. This “better together” capability means that not only does SQL Server store the objects and

configurations of SharePoint, but it also provides on-demand and self-service business intelligence, list

generation and PowerPivot capabilities.

SharePoint Designer

SharePoint Designer is the mechanism the IT Professionals and Power Users can use to create workflows,

design custom pages and other tasks that are not available in the SharePoint interface itself.

SharePoint 2010 Architecture for Compliance

When you bring all the pieces and parts together, you end up with a general architecture for compliance that

includes capabilities for workflow, electronic and digital signatures, document retention and archival and

audit trails or histories to prove that the signatures and documents are valid.


While the overall architectural components are important, it is also key to identify proper organization, sizing

of the server farm, navigation and other concepts. Those elements are largely outside scope of this

document.

For information on the concepts of sizing, navigation and geographical disbursement, please visit

http://msdn.microsoft.com as well as http://www.microsoft.com/itshowcase for best practice information on

SharePoint implementation on an enterprise scale.

Database Security

21 CFR 11.10(d) notes that access to IT applications must be limited to authorized individuals. In addition to

internal safeguards built into a computerized system, external safeguards and policies should be put in place

to ensure that access to the computerized system and to the data is restricted to authorized personnel. Staff

should be kept thoroughly aware through training and procedures of system security measures and the

importance of limiting access to authorized personnel. Procedures and controls should be put in place to

prevent the altering, browsing, querying, or reporting of data via external software applications that do not

enter through the protective system software. IT guidelines, standard operating procedures and controls

typically ensure that access to back-end servers and applications is controlled.

There is a potential security issue where a person with elevated permissions to the WSS-Content-Database

could alter records in the database table and impact the Signed Person, Date signed, and Purpose of Signing

tables. Per typical IT operating measures, people with elevated permissions are typically authorized and

working under strict operating procedures. The likelihood of malicious changes is low. However, if someone

did alter the underlying database tables, SharePoint will not recognize these changes; hence the signature

would become invalidated.

Windows Server 2008 R2

Active

Directory

Rights

Management

Services

Certificate

Services

FAST

Enterprise

Search

SQL Server 2008 R2

SharePoint 2010

Document

Mgmt Policy Mgmt Workflow

Records

Mgmt

Electronic &

Digital

Signature

Workflow

http://msdn.microsoft.com/

http://www.microsoft.com/itshowcase


If this is viewed as a security issue not handled well enough by internal IT operating procedures, there are

options. To fix this issue, an encryption key can be generated and stored in the document library. This key

would be used to determine if changes were made to the document properties using SQL update. A hash

key can be generated using the following columns from the document library:

Signer Name

Purpose of Signing

DateTime (of signing)

Version of the Document

Document Status

A timer service can run to check approved documents to see if any changes were made in the WSS-Content-

Database. The encryption key is examined, and any changes noted will invalidate the document. If the

document is found to be invalid, a workflow will be invoked to send an email to the signer and/or an

administrator to note that the document has been changed by an unknown person and hence the

document is invalid.

There are other options for achieving this level of check and balance to ensure that a malicious activity at the

database level is discovered and accounted for. However, for most organizations internal IT operating

procedures preclude unauthorized access to servers and applications.

Configuring the Electronic

Signature Use Cases Electronic signatures are a central component to 21 CFR Part 11 compliance. As specified in the use cases,

we’ll detail two mechanisms for electronic signatures: single signature documents and documents that

require multiple signatures.

In both use cases the configuration chosen makes a few key decisions:

While not necessary, the electronically signed documents will contain a representation of the

signature that includes the name of the signing party, the date of the signature and the reason for

signing.

Once signed, the document will be protected through Rights Management, so that the signed

version cannot be tampered with, but it may also be used to create another version.

The electronic signature will remain in the document as well as in the audit trail/version history of

that document.

Workflow can take the final electronically signed document and copy it to the records center for

final disposition and archival.

Administrator Configuration for Single Signatures

To support the use case where the process requires a single electronic signature per document the site

administrator will do the following tasks:


Configure document library templates

The first task is to select the document library to be enabled for electronic signatures.

Once in the target document library, click on the Library tab in the Ribbon Bar. This brings you to the

Document Library Settings page which enables you to add the necessary columns for electronic signatures.

To add columns in the document library click Library Tools > Library > Document Library Settings >

Create columns.


The following columns will be added:

Username

Purpose of Signature

Document Status (needed for workflow processing)

Date Signed

Signers

To add columns in the document library click Library Tools > Library > Document Library Settings >

Create columns.


After adding the necessary columns, while still in the Document Library Settings, click on Versioning

Settings.


This brings you to Document Library > Document Library Settings > Versioning Settings screen which

enables you to control the versioning for the document library.

Under Require content approval for submitted documents, click Yes.

Click Create major versions, or other settings as needed by your company’s policies and procedures.

Configure Document Library Version Histories

After adding the necessary columns, while still in the Document Library Settings, click Versioning Settings.

This brings you to Document Library > Document Library Settings > Versioning Settings screen which

enables you to control the versioning for the document library.

Under Require content approval for submitted documents, click Yes.

Click Create major versions, or other settings as needed by your company’s policies and procedures.

Once you click Submit for the Versioning Settings screen, you will be returned to Document Library >

Document Library Settings screen.

This turns on the audit trail functionality, which allows users to be able to view the audit trail of the system

through simple reports. In the Document Library those changes can be reflected in the document view itself

on a document by document basis.


For Centralized Audit Reporting, an administrator would need to turn on this feature under Site Actions >

Site Settings > Site Collection Audit Settings.

Configure Document Templates for Workflow and Signatures

In order to set the document templates needed for electronic signatures, click on Advanced Settings in the

Document Library > Document Library Settings screen.


In Document Library > Document Library Settings > Advanced Settings Screen, click Edit Template in

the Document Template section under the Template URL: dialog.

This will launch the template editor in Microsoft Word. Click on the Insert tab in the Ribbon Bar. On the

Insert Tab, click on the Quick Parts > Document Property dialog and pull-down.


Drag and drop the fields DateSigned, DocumentStatus, PurposeOfSignature,Username and other fields

added to the document library to support electronic signatures.

This then results in a document that has a signature line added in through metadata.

Note that this document, once signed, can be protected via Rights Management Service so that it cannot be

modified once signed, even if e-mailed or a thumb drive used to copy the document elsewhere.

Once Rights Management has been set up for a SharePoint site, setting rights on any given document is as

simple as having the document inserted or created in a document library with specific rights.

Those permissions—or rights—are then inherited by all the documents in that library, or items in a list. This

means that with the appropriate rights set on the document library, as shown in this document, you have the

ability to lock down documents—with or without a formal records declaration—and prevent those

documents from being changed by those without permissions.


Create Workflows for Electronic Signatures

In order to create the workflows necessary to support electronic signatures, you will need to open

SharePoint Designer.

Once in SharePoint Designer, click on the File tab, then the Open Site button. If the site is displayed in the

Recent Sites, then click to open that site.



To create an electronic signature workflow, click on the Workflows link under Navigation > Site Objects.

Once the workflow tab is open, click on the Workflows tab in the Ribbon Bar, and then click on the List

Workflow button.

To configure the workflow for the electronic signature document library, click on the appropriate document

library name in the List Workflow pull-down.


In creating the workflow, the first step is to add condition checks for Approval Status. This will use the

Content Approval Status column in the list library. This condition check will determine if the document is

Approved, Rejected, or if the document is already signed.



You can then define the e-mail message that can be sent to the users involved in the workflow. This is

configured through steps during the SharePoint design Workflow creation process. (See Define E-mail

Message below.)

To do this, simply go to Actions > Send an Email.



Note, again, that the document, when placed into a library can inherit the permissions – and Information

Rights Management Policies through RMS. Since RMS is not an inherently necessary part of Part 11

compliance, please see the MSDN documents on the topic.

Create a Signature Page

The one area of SharePoint that requires customized code to comply with current guidance on 21 CFR Part

11 is on the Signature Page.

Many other federal regulations utilize electronic signatures. But 21 CFR Part 11 is the only one with a

concept of a signing password , where the user re-authenticates in order to validate the signing event. In

most other federal regulations, it is sufficient for the user to a) be authenticated and then during the signing

event simply type in their full name as evidence that they are signing the record.

To meet the re-authentication for the signing event, in this case, simply requires 12 lines of code. Creating

the signing page with all the buttons requires more code—but that can be done through other methods

besides code, including SharePoint designer. The primary step here is attaching the authentication code to

the workflow

The code itself is relatively straightforward. Written in C#, the basic idea of the code is to take the users

username and password and authenticate against LDAP—this is done in the ValidateActiveDirectoryLogin

function below:

/// <summary>

/// Method to validate user for a given credentials

/// </summary>

/// <param name= domain ></param>

/// <param name= username ></param>

/// <param name= password ></param>

/// <returns>Boolean returns true if success</returns>


protected Boolean ValidateActiveDirectoryLogin(string domain, string username, string password)

{

Boolean success = false;

System.DirectoryServices.DirectoryEntry Entry = new System.DirectoryServices.DirectoryEntry( LDAP:// + domain, username, password);

DirectorySearcher searcher = new DirectorySearcher(Entry);

searcher.SearchScope = System.DirectoryServices.SearchScope.Subtree;

try

{

searcher.Filter = (SAMAccountName= + username + ) ;

searcher.PropertiesToLoad.Add( cn );

System.DirectoryServices.SearchResult results = searcher.FindOne();

// userFullName = results.GetDirectoryEntry().Properties[ CN ].Value.ToString();

success = (results != null);

}

catch (Exception ex)

{

success = false;

lblMessage.Text = Error: + ex.Message;

}

return success;

}

Full source code for all the functions will be provided as an appendix to this whitepaper.

Using the provided source code, the signature page appears as follows.


Though not required, as the signature is stored with the document in SharePoint, it is a nice touch that helps

users know that a signature has been applied to a given document. Thus, in the solution provided, code was

added to append the signature to the document itself. In addition, the document is protected by rights

management as part of the workflow cycle, so that no changes can be made to the document once signed.

It is important to note that this is still an electronic signature and not a digital signature. The configuration

methods for digital signatures are provided later in the document.


Set Permissions for the Document Library

SharePoint 2010 has the ability to set permissions on the Document level, Document Library level and site

level.

To set permissions for a document library, navigate to your document library, and then click on Library >

Library Permissions.

Set Policies for the Document Library

One of the more important aspects of configuring SharePoint 2010 for 21 CFR part 11 compliance is

configuring site wide policies that dictate permission levels and rules. This is done to prevent users

particularly content administrators from changing permission levels that would invalidate the compliance of

any given document library.

To configure site wide auditing:

Go to Site Actions > Site Settings > Site Collection Audit Settings

To add stage properties for a document library go to Document library settings > Information

Management Policy Settings.


Click Change Resource link to change staging properties for the documents library.


On clicking the hyper link Add Retention stage the below popup will be shown to configure the document

into Records Center.

Note that the Content Organizer can also be used to send records into the records center that are subject to

Part 11 compliance based on their content-type.


Once delivered to its final destination after approval, the document is automatically declared a record.


Navigate to Site Actions > Site Settings > Record Declaration Settings for globally setting this

throughout the site.

The last step in the process is creating the Custom Permission Levels for Site Roles, so Versioning, Content

Approval Settings, and Workflow can’t be manipulated.


This is an important consideration for Part 11 compliance, as it assures – with proper configuration – that the

audit histories, electronic signatures and other vital information for compliance is not changed in any

fashion.

This configuration of SharePoint and workflow has all records transferred to their preferred locations via the

records retention policies based on the Signed Doc attribute. When the Document becomes approved, then

the attribute is set as a record inside the workflow.

For more information on the process of transferring signed documents to the records center, see

http://technet.microsoft.com/en-us/library/ee424395.aspx

http://technet.microsoft.com/en-us/library/ee424395.aspx


Once in the target document library, click on the Library tab in the Ribbon Bar. This brings you to the

Document Library Settings page which enables you to add the necessary columns for electronic signatures.

The following columns will be added, which include the single signature columns as well as additional

columns for multiple signatures:

Username

Purpose of Signature


Date Signed

Signers

Additional fields as outlined below.

The steps for setting version history and version control are the same as for creating single electronic

signatures.

Configure Document Templates for Workflow and Multiple Signatures

In order to set the document templates needed for multiple electronic signatures in a single document, click

on Advanced Settings in the Document Library > Document Library Settings screen.


In Document Library > Document Library Settings > Advanced Settings Screen click Edit Template in

the Document Template section under the Template URL: dialog.

This will launch the template editor in Microsoft Word. Click on the Insert tab in the Ribbon Bar, and then

click on the Quick Parts > Document Property dialog and pull-down.

Drag and drop the fields DateSigned, DocumentStatus, PurposeOfSignature, Username and other fields

added to the document library to support electronic signatures.


This then results in a document that has a signature line added in through metadata. Note that this

document, once signed, can be protected via Rights Management Service so that it cannot be modified once

signed, even if emailed or a thumb drive is used to copy the document elsewhere.


Create Workflows for Multiple Electronic Signatures

In order to create the workflows necessary to support electronic signatures, you will need to open

SharePoint Designer.

Once in SharePoint Designer, click on the File tab, then the Open Site button. If the site is displayed in the

Recent Sites, then click to open that site.


To create an electronic signature workflow, click on the Workflows link under Navigation > Site Objects.

Once the workflow tab is open, click on the Workflows tab in the Ribbon Bar, then click on the List

Workflow button.


To configure the workflow for the electronic signature document library, click on the appropriate document

library name in the List Workflow pull-down.


In creating the workflow, the first step is to add condition checks for Approval Status. This will use the

Content Approval Status column in the list library. This condition check will determine if the document is

Approved, Rejected, or if the document is already signed.


You can then define the e-mail message that can be sent to the users involved in the workflow.

Go to Actions > Send an Email and configure properties appropriately.



Again, it is important to note that while not necessary for Part 11 compliance, the use of Rights Management

Service in conjunction with SharePoint will ensure that the rights become part of the document itself,

originally applied as part of workflow or when a document is loaded into the document library.


The instructions for updating SharePoint for Information Rights Management can be found on MSDN.


The signature page for multiple signatures is the same as for single signatures.

The final signed document with the signatures appears as follows:


The methods for setting permissions for the document library are the same as for single signatures.

To set permissions for a document library, navigate to the document library, and then click on Library >

Library Permissions.



The methods for setting policies for the document library are the same for multiple signatures as they are for

single signatures.

Digital Signatures Use Case The following scenarios detail configuring SharePoint 2010 and Office 2010 to use digital signatures based

on X.509 Certificates. Note that the provisioning and deployment of those signatures are outside the scope

of this document.

Configuring Digital Signatures in SharePoint and Office 2010 is far simpler than configuring electronic

signatures and provides a higher level of security and assurance than simple electronic signatures, even with

the added features detailed earlier in this document.

In fact, SharePoint 2010 comes with an out of the box Approval Workflow called a “Collect Signatures”

workflow. This document will utilize a variant of that workflow for the Digital Signatures use case.

Administrator Configuration for Digital Signatures

Similar steps are required for creating workflows for Digital Signatures as they are for Electronic Signatures.

Configure Document Library Templates

Creating the document library templates is essential, as this provides the signature blocks that will be used

during the X.509 certificate signature process.

As with the electronic signatures, you first select the document library that will be used for the Digital

Signatures. When there, click on the Library Tool >Library tab in the Ribbon Bar. This brings you to the

Document Library Settings page which enables you to add the necessary columns for digital signatures.

The following column will be added:



Date Signed

Signers

Configure Document Library Version Histories

While digital signatures are more secure than electronic signatures, it is still important to create and set

version histories for the audit trail capabilities of the document library.

The steps for doing this are the same as for configuring electronic signatures.

Configure Document Templates for Workflow and Digital Signatures

Setting the document templates for digital signatures is straight forward. In the Document Library>

Document Library Settings screen, click on Advanced Settings.

In the Document Library > Document Library Settings > Advanced Settings screen click Edit Template

in the Document Template section under the Template URL: dialog.


This will launch the template editor in Microsoft Word.

The first step in adding a digital signature to the document is by going to the Office 2010 BackStage by

clicking on the File tab in the Ribbon Bar. Then under Protect Document click on Add Digital Signature.

Once the Digital Signature is added, you’ll want to navigate to the section of the document that will contain

the signature. To insert the Signature at that location, click on the Insert tab in the Ribbon Bar, and then click

on the Signature Line drop down.


This will enable you to insert a signature block or multiple signature blocks. In addition, this drop down

provides for multiple signature providers. This enables different certificates.

Once inserted, an unsigned signature block – or multiple blocks – looks as such:

The signature block can also be a stamped signature, such as would be done for a SAFE BioPharma logo.

In signing a document, the user is prompted for “Comment” which is generally used as the ‘Purpose for

Signing’. It is also possible to create a custom signature event, such as one for SAFE BioPharma that is

located at http://www.codeplex.com/safe

Once used by the signer, the signature block appears as such:

Note that digitally signing a document also makes that document read-only. Saving the document and

making any changes invalidates and removes the signature (but not the unsigned signature block) from the

document.

http://www.codeplex.com/safe


Also important to discuss is the role of Rights Management, which can be applied to a document before the

signature process, further protecting the document from change.

Create Workflows for Digital Signatures

Creating workflows that utilize digital signatures is actually more straightforward than for electronic

signatures. These workflows can either be created in SharePoint itself, or through SharePoint Designer.

In fact, as mentioned previously, SharePoint 2010 contains out of the box workflows for digital signatures, in

this called “Collect Signatures”.

The MSDN Article used to configure this part of the document can be found at:

http://office.microsoft.com/en-us/sharepoint-server-help/use-a-collect-signatures-workflow-

HA010154428.aspx

Along with more basic articles on approval workflow: http://office.microsoft.com/en-us/sharepoint-designer-

help/understand-approval-workflows-in-sharepoint-2010-HA101857172.aspx?CTT=1

Add or Change a Collect Signatures Workflow

Before a Collect Signatures workflow can be used, it must be added to a library or content type to make it

available for document or items in a specific location.

The Collect Signatures workflow is intended primarily for use in libraries and can be started only on

documents that open in Office Word 2007 or Office Excel 2007. You must have the Manage Lists permission

to add a workflow to a library or content type. In most cases, site administrators or individuals who manage

specific lists or libraries perform this task.

The availability of the workflow within a site varies, depending on where it is added:

If you add a workflow directly to a library, it is available only for documents in that library.

If you add a workflow to a list content type (an instance of a site content type that was added to a

specific library), it is available only for items of that content type in the specific library with which

that content type is associated.

If you add a workflow to a site content type, that workflow is available for any items of that content

type in every list and library to which an instance of that site content type was added. If you want a

workflow to be widely available across libraries in a site collection for items of a specific content

type, the most efficient way to achieve this result is by adding that workflow directly to a site

content type.

Add or Change a Collect Signatures Workflow for a Library or Content Type

If you want to add a Collect Signatures workflow to a library or content type, or if you want to change a

Collect Signatures workflow that is already associated with a library or content type, you follow the same

steps.

1. To go to the Add a Workflow page or the Change a Workflow page for the library or content

type to which you want to add a workflow, do one of the following:

For a Library:

1. Open the library to which you want to add or change a workflow.

2. On the Settings menu, click the settings for the type of library that you are opening. For

example, in a document library, click Document Library Settings.

http://office.microsoft.com/en-us/sharepoint-server-help/use-a-collect-signatures-workflow-HA010154428.aspx

http://office.microsoft.com/en-us/sharepoint-server-help/use-a-collect-signatures-workflow-HA010154428.aspx

http://office.microsoft.com/en-us/sharepoint-designer-help/understand-approval-workflows-in-sharepoint-2010-HA101857172.aspx?CTT=1

http://office.microsoft.com/en-us/sharepoint-designer-help/understand-approval-workflows-in-sharepoint-2010-HA101857172.aspx?CTT=1


3. Under Permissions and Management, click Workflow settings.

For a List content type:

1. Open the library that contains the instance of the list content type for which you want to

add or change a workflow.

2. On the Settings menu , click the settings for the type of library that you are opening. For

example, in a document library, click Document Library Settings.

3. Under Content Types, click the name of the content type.

For a site content type:

1. On the home page for the site collection, on the Site Actions menu, point to Site

Settings, and then click Modify All Site Settings.

2. Under Galleries, click Site content types. \

3. Click the name of the site content type for which you want to add or change a workflow,

and then click Workflow settings.

Note: If workflows have already been added to this library or content type, this step takes

you directly to the Change Workflow Settings page, and you need to click Add a

workflow to go to the Add a Workflow page. If no workflows have been added to this

library or content type, this step takes you directly to the Add a Workflow page.

4. On the Change Workflow Settings page, click Add a workflow or click the name of the

workflow for which you want to change the settings.

2. Do one of the following:

If you are adding a workflow, on the Add a Workflow page, in the Workflow section, click the

Collect Signatures workflow template.

If you are changing the settings for a workflow, on the Change a Workflow page, change the

settings that you want to change according to the following steps.

In the Name section, type a unique name for the workflow.

In the Task List section, specify a tasks list to use with this workflow.

Note: You can use the default Tasks list or you can create a new one. If you use the default

Tasks list, workflow participants will be able to find and view their workflow tasks easily by

using the My Tasks view of the Tasks list.

If the tasks for this workflow will reveal sensitive or confidential data that you want to keep

separate from the general Tasks list, you should create a new tasks list.

If your organization will have numerous workflows or if workflows will involve numerous tasks,

you should create a new tasks list. In this instance, you might want to create tasks lists for each

workflow.

In the History List section, select a history list to use with this workflow. The history list

displays all of the events that occur during each instance of the workflow.

You can use the default History list or you can create a new one. If your organization will have

numerous workflows, you might want to create a separate history list for each workflow.

In the Start Options section, specify how, when, or by whom a workflow can be started.

Notes: Specific options may not be available if they are not supported by the workflow

template that you selected.


The option Start this workflow to approve publishing a major version of an item is

available only if support for major and minor versioning is enabled for the library and if the

workflow template that you selected can be used for content approval.

If you are adding this workflow to a site content type, specify whether you want to add this

workflow to all content types that inherit from this content type in the Update List and Site

Content Types section.

Note: The Update List and Site Content Types section appears on the Add a Workflow page

only for site content types.

3. Click OK.

Start a Collect Signatures Workflow on a Document or Workbook

Before you can start a Collect Signatures workflow, you must save the document or workbook for which you

want to collect signatures to a SharePoint library for which the Collect Signatures workflow is available. You

must have at least the Edit Items permission to start a workflow. Some workflows may require that you also

have the Manage Lists permission in order to start a workflow on a document or item.

Note: If you want to ensure that workflow participants receive e-mail notifications and reminders about their

workflow tasks after you start a workflow, check with your server administrator to verify that e-mail

notifications have been enabled for your site.

1. If the library is not already open, click its name on the Quick Launch. If the name of your library

does not appear, click View All Site Content, and then click the name of your library.

2. Point to the document or workbook on which you want to start a Collect Signatures workflow, click

the arrow that appears, and then click Edit in Program Name.

3. If the document or workbook does not already contain signature lines to capture the digital

signatures that you want to collect, insert them now as described previously and repeated below. If

you add new signature lines, click the File tab, and then click Save to save your changes.

4. If the document is checked out, you must also check in the document before you start the

workflow. To check in the document, click the File tab, point to Server, and then click Check In.

5. For the user to start the workflow, click the File tab, and then click Workflows. In the Workflows

dialog box, locate the Collect Signatures workflow that you want to use, and then click Start.

6. In the Workflow Name dialog box, type the names of the people you want to sign the document

on the appropriate signers lines, or click Signer to select people from the directory service.

7. If you want to assign the signature tasks in the order in which signature lines appear in the

document, select the Request signatures in the order above, rather than all at once check box.

8. If you want other people to receive notifications (not task assignments) when the workflow is

started, type their names on the CC line, or click CC to select people and groups from the directory

service.

9. Click Start.


Starting with Office 2007 and continuing with Office 2010, Signature Pages for Digital Signatures are out-of-

the-box.

To sign a document, right click on the Signature Block as shown above, select the certificate to be used,

provide the reason for signing, and click OK.


You will be prompted for your Digital Certificate PIN and/or to insert your SmartCard or Token. Once the PIN

is authenticated against the card or token, the signature is placed within the document and the document is

made read-only.

The only change that can be made to a signed document is to add another signature.


These steps are the same as for electronic signatures.


These steps are the same as for electronic signatures.

View the Version Histories for Digital Signatures

Auditing digitally signed documents can be done in a couple ways: within the document itself as XAdES

requires the signing history be kept with the document and also through the SharePoint version history.

To view additional information and signature history of the document:

1. Open the file that contains the signatures that you want to view.

2. Click the File tab. The Microsoft Office Backstage view opens.

3. Click the Info tab.

4. Click View Signatures.

5. The Signatures pane appears with a list of signatures.

The following image is an example of the Signatures pane.

6. In the Signature pane, next to the signature name, click the down arrow and select Signature

Details.


7. The Signature Details dialog appears. Click See the additional signing information that was

collected.

8. The Additional Information dialog appears.

The following image is an example of the Additional Information dialog.

The following signature information appears:

What the signature signs

Local date and time the signature was applied

The version of the Microsoft Windows operating system installed

The version of Microsoft Office installed

The version of the Microsoft Office program used

The number of monitors installed

Monitor resolution

You can view the message that indicates the file is not showing hidden content.


21 CFR Part 11 Requirements Subpart B Addressed / Not Addressed

11.10 Controls for closed systems Addressed

11.10 (a) Validation of systems Addressed

11.10 (b) Record review and inspection Addressed

11.10 (c) Records protection and retrieval Addressed

11.10 (d) System access Addressed

11.10 (e) Audit trail Addressed

11.10 (f) Operational system checks Addressed

11.10 (g) Protect record from unauthorized access Addressed

11.10 (h) Data input validation Addressed

11.10 (i) Personnel training Not applicable

11.10 (j) Electronic signature policy Addressed

11.10 (k) System control Addressed

11.30 Controls for open system Addressed

11.50 Signature manifestation Addressed

11.50 (a) Signature information Addressed

11.50 (b) Control of signature information Addressed

11.70 Signature/record linking. Addressed

Subpart C

11.100 General requirements. Not applicable

11.100 (a) Uniqueness Not applicable

11.100 (b) Identity verification Not applicable

11.100 (c) Legal certification Not applicable

11.200 Electronic signature components and controls Addressed

11.200 (a) Non-biometric signature Addressed

11.200 (b) Genuine use of biometrics signature Not applicable

11.300 Controls for credentials Addressed

11.300 (a) Maintain of credentials uniqueness Addressed

11.300 (b) Credential maintenance Addressed

11.300 (c) Process for lost or compromised credentials Addressed

11.300 (d) Safeguard to unauthorized credential use Addressed

11.300 (e) Device maintenance Not applicable


Subpart B Electronic Records 11.10 Controls for Closed Systems

Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ

procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the

confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record

as not genuine.

As the previous configurations demonstrate, SharePoint Server addresses authenticity, integrity and

confidentiality of electronic records through access control and permission to the records on either the

individual record level or a document library level. Users are assigned permissions to content and records

through permissions which limit what they can do by administrators. Documents identified as records can be

sent to a record center for safe keeping and have separate access control than when the document was

authored and reviewed.

To protect confidentiality of an electronic record, documents can be protected by Information Rights

Management (IRM) policy that could restrict users from copying or printing documents even after the

document is saved outside of the SharePoint Server.

SharePoint also addresses non-repudiation through audit trails as demonstrated. The auditable system of

records are implemented through policies which can be configured for documents and items in Office

SharePoint Server 2010 to specify which events will be audited for each Content Type or site level, via the

Information Management Policy capabilities. An audit trail is kept with a document throughout the

document and record life cycle.

11.10 (a) Validation of Systems

Systems validation ensures accuracy, reliability, consistent intended performance, and the ability to discern

invalid or altered records.

How Office 2010 System Addresses the Requirement

Addressing this requirement takes a couple forms: 1) Validation of the system as a whole, and 2) validation

of the individual documents or records.

To address validation of the system, there are three areas of validation that implementing parties need to be

concerned with: IQ (Installation Qualification), OQ (Operational Qualification) and PQ (Performance

Qualification).

In the case of Installation Qualification, the focus is on ensuring that the application is installed correctly, and

all Microsoft product generated installation logs are maintained which detail the installation as well as any

errors that may arise during the installation process.

In addition, Microsoft Systems Center can provide installation audit trails for SharePoint implementations to

ensure that all components installed properly.

Operational Qualification begins with the development methodology utilized to create the software. Most

Microsoft products, and all the products detailed in this whitepaper, adhere to the Security Development

Lifecycle methodology. This methodology, which encompasses steps traditionally employed in software

development methodology, places a particular focus on development of software that is secured by design,

in development, and through implementation. All major software releases from Microsoft, beginning with

the Office 2007 and Vista/Longhorn wave of software releases are required to go through the internal


processes and checkpoints detailed in the Security Development Lifecycle methodology, and must be signed

off on by a Security Officer before the particular software can be released to the general public.

The details of the methodology are available on MSDN as well as through published works by Steve Lipner

and Michael Howard (see the Reference section for more information).

In addition, there is a whitepaper available entitled “Mapping Microsoft Development Methodology to the

V-Model” that is available on MSDN as well.

Operational Qualification extends to the operation of the software. To that end, most Microsoft software,

and all the products detailed in this whitepaper, provide detailed error logging and troubleshooting

information that can be gained through a proper implementation of the Microsoft Systems Center

Operations Manager. In fact, any software release must include a management pack for Operations Manager

before the particular software can be released to the general public.

The details of the management pack for all relevant software are available in the References section of this

document.

Performance Qualification always includes the question, “Does the software perform to the end users’

needs?” As that question can only be answered by the implementing party, the final step in validation of the

software needs to be the development of test plans and testing of the software in the environment in which

it will be utilized. These test plans can be modeled on this whitepaper to assist with the proper configuration

of the software.

While the overall validation of the software is up to the implementing party, Microsoft has assisted in the

validation through the creation of the development methodology, implementation of management packs,

implementation of the installation logs, and development of this whitepaper to give guidance in the

configuration of the software and development of the test plans for performance qualification.

Finally, Microsoft recommends that companies periodically audit their own implementation of the software,

in order to ensure that the guidelines specified herein are applied to their production systems and are

enforced throughout.

To address validation of the individual documents, SharePoint provides auditing features to facilitate the

validation process.

As SharePoint server is designed as an auditable system, the administrator can configure the system to audit

document creation, specifically document modification and deletion among other things so all changes to a

document are audited. Additionally, you can also extend the auditing capabilities to include additional

information such as version and workflow status.

All these capabilities related to SharePoint were demonstrated in the configurations detailed in the use cases

section of this Whitepaper

11.10 (b) Record Review and Inspection

The ability to generate accurate and complete copies of records in both human readable and electronic form

suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are

any questions regarding the ability of the agency to perform such review and copying of the electronic

records.


As shown in the configuration methods, SharePoint has the ability to generate accurate and complete copies

of records in both human readable and electronic form.

Additionally, when the documents in question are written in the Microsoft Office 2010 system, the OpenXML

file format allows the document to be accessible electronically (i.e. machine readable in XML in its

component parts) while still maintaining the ability to be viewed as a whole through Word, Excel, or

PowerPoint as appropriate. Saving the document in XML Paper Specification (XPS) format provides the best


of both worlds: a machine readable document (in XML) whose formatting does not change regardless of the

printer, screen, or viewing application used to display the document.

For a description of the OpenXML format, refer to http://www.ecma

international.org/publications/standards/Ecma-376.htm

For a description of the XML Paper Specification (XPS), refer to

http://www.microsoft.com/whdc/xps/downloads.mspx

Both XPS and OpenXML are native file formats for Office 2010 and are understood and readable by the

Windows 7 operating system as well.

Agencies and inspectors can be given read-only access to documents during the review process. Electronic

documents will be viewed either natively or in other formats via document converters or viewers.

11.10 (c) Records Protection and Retrieval

Protection of records to enable their accurate and ready retrieval throughout the records retention period.


As discussed in the configuration section, SharePoint 2010 protects documents through content policies that

prevent documents from being changed. In addition, the system then takes the documents declared as

records and can flag them for retention for a specific period of time.

1. Automatically receive/route records declared from other sources—Records Centers are able to

determine how the Content Type of a declared record translates to an appropriate record series in

the file plan, and then file the record into the appropriate location.

2. Hold orders: The Records Center includes a powerful hold order system to locate records relevant

to particular event requiring a hold order, suspending disposition of those records for the duration

of the event, and for resuming normal disposition once those events have ended.

3. Separate access controls: Records Center can give you the flexibility to specify whether users can

access any section of the Records Center, whether they can view or add items, independent of the

permissions those users have on authoring and collaboration sites.

As demonstrated, documents can be attached to a policy that defines content expiration and version control

policy.

Microsoft Office technology allows content that is outside the repository to be secured on the basis of

policies as well by using the Rights Management Server. With the 2010 system, an access control policy set

up for a SharePoint site can also be maintained for documents on the desktop. These rights also extend to

expiration, printing, forwarding, and copying, thereby ensuring a higher level of content security than has

been possible with traditional approaches.

11.10 (d) System Access

Limiting system access to authorized individuals.


SharePoint sites containing information or documents to be protected should not allow anonymous access.

The User will need to be authenticated before access to the site is granted.

The following are authentication methods for SharePoint (or any ASP.NET application):

Windows integrated (NTLM, Kerberos, or certificate) – user is authenticated when they log on their

computer. This is enforced by IIS.

http://www.ecma-international.org/publications/standards/Ecma-376.htm

http://www.ecma-international.org/publications/standards/Ecma-376.htm

http://www.microsoft.com/whdc/xps/downloads.mspx


Basic authentication – user enters domain credentials for authentication before access to the site is

granted. This is enforced by IIS. As credentials are sent as plain text by default, this option should

use SSL or other mechanism to encrypt the http traffic.

Forms based or SSO – user enters credentials assigned to them that may not be their domain

credentials. As with Basic Authentication, HTTP traffic needs to be encrypted to protect the

credentials. This requires additional settings on web.config file for the web application.

Authentication setting is set per web application (the container that hosts portal and collaboration sites) and

is configured through SharePoint Central Administration Application.

The following is a sample web.config file used to setup forms-based authentication, role-based access, and

denies access to unauthenticated users:

<configuration>

<connectionStrings>

<add name= MySqlConnection connectionString= Data

Source=MySqlServer;Initial Catalog=aspnetdb;Integrated

Security=SSPI; />

</connectionStrings>

<system.web>

<authentication mode= Forms >

<forms loginUrl= login.aspx

name= .ASPXFORMSAUTH />

</authentication>

<authorization>

<deny users= ? />

</authorization>

<membership defaultProvider= SqlProvider userIsOnlineTimeWindow= 15 >

<providers>

<clear />

<add

name= SqlProvider

type= System.Web.Security.SqlMembershipProvider

connectionStringName= MySqlConnection

applicationName= MyApplication

enablePasswordRetrieval= false

enablePasswordReset= true

requiresQuestionAndAnswer= true

requiresUniqueEmail= true

passwordFormat= Hashed />

</providers>


</membership>

<roleManager defaultProvider= SqlProvider

enabled= true

cacheRolesInCookie= true

cookieName= .ASPROLES

cookieTimeout= 30

cookiePath= /

cookieRequireSSL= false

cookieSlidingExpiration= true

cookieProtection= All >

<providers>

<add

name= SqlProvider

type= System.Web.Security.SqlRoleProvider

connectionStringName= MySqlConnection

applicationName= MyApplication />

</providers>

</roleManager>

</system.web>

</configuration>

After authentication, the user will also need to be assigned appropriate rights to access specific features and

contents. Details on how to configure user roles and rights are discussed in Section 11.10 (g) of this paper.

11.10 (e) Audit Trail

Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of

operator entries and actions that create, modify, or delete electronic records. Record changes shall not

obscure previously recorded information. Such audit trail documentation shall be retained for a period at

least as long as that required for the subject electronic records and shall be available for agency review and

copying.


As discussed in 11.10 (a) audit trails in SharePoint are provided at the document level, document library level

and at the site level. These capabilities were demonstrated in the configuration section of this document.

11.10 (f) Operational System Checks

Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate



As demonstrated in the configuration section, SharePoint 2010 can enforce workflow, audit trails and

electronic signatures on any given document.

11.10 (g) Protect Records from Unauthorized Access

Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a

record, access the operation or computer system input or output device, alter a record, or perform the

operation at hand.


As demonstrated, SharePoint Server 2010 controls access to Web sites, lists, folders, and list items through a

role-based membership system by which users are assigned to roles that authorize their access to Windows

SharePoint Services objects. The creation and authentication of the user and to which role the user is

assigned is discussed in Section 11.300 – Controls for Identification Codes / Passwords.

To give a user access to an object, you either add the user to a group that already has permissions on the

object, or create a role assignment object, setting the user for the role assignment and then adding the

assignment to the collection of role assignments for the object (such as list item, folder, list, or Web site).

By default, objects inherit permissions from their parent (document from document library or folder,

document library from site, site from parent site).

Following are the screen shots of defining a unique permission setting for a document.

11.10 (h) Data Input Validation

Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or

operational instruction.


Transport level encryption (such as SSL) can be used to secure the content (data input) from users.

ASP.NET (which SharePoint is built on) uses the Message Authentication Code (MAC) technique to protect

key information, such as view state data and authentication tickets, to make sure that the data are not

illegally modified.

For cookie-based authentication (such as forms authentication), administrators can configure cookie timeout

parameters to be reasonably short to reduce the cookie reply security risk.

For additional protection, Microsoft has developed Forefront Security for SharePoint, which helps businesses

protect their Microsoft Office SharePoint Server 2010 servers from viruses, unwanted files and inappropriate

content. With a layered, multiple scan engine approach, Forefront Security for SharePoint helps stop the

latest threats before they impact your business and users.

11.10 (i) Training

Determination that persons who develop, maintain, or use electronic record/electronic signature systems

have the education, training, and experience to perform their assigned tasks.


Microsoft product teams follow rigorous development and testing processes for its product development

including the Office 2010 systems, as described in Section 11.10(a) Validation of Systems.


Microsoft and many of its partners offer extensive training courses, technical resources, and certifications for

.NET, SharePoint and related technologies to help organizations to educate and train their people for specific

tasks.

11.10 (j) Electronic Signature Policy

The establishment of, and adherence to, written policies that hold individuals accountable and responsible

for actions initiated under their electronic signatures, in order to deter record and signature falsification.


While the establishment of a Electronic Signature Policy is the responsibility of the implementing

organization, the Office 2010 can assist in the adherence to those written policies by implementing Records

Management that reflect and enforce those policies.

Creating a successful Records Management system starts with mapping out the organization’s records

management goals, anticipating the challenges an organization will face in making that vision a reality within

the company, and developing a policy and implementation that fits these needs. Since planning is a key to

both the policy development and solution implementation phases, it is important to outline the challenges

faced at each stage so these can be kept top of mind when working out both the organization policy plan

and implementation strategy.

At the policy planning stage, the major challenge is to devise a system that encompasses an organization’s

current records-keeping needs: content types, media types, storage requirements, business processes, and

policies. It also needs to meet present legal and audit requirements, and be extensible and flexible enough

to accommodate future content types and retention requirements. Another important goal is to enhance

information retrieval, which will help employees do their jobs more efficiently and give an organization a

competitive advantage.

In developing the policy for an organization, the challenge is to create an overarching policy document that

is comprehensive but short, easy to read, and accompanied by actionable retention schedules that can then

be put into practical use. Furthermore the policy needs to be integrated with the organization’s other

enterprise content management policies, and be able to absorb and integrate previous record keeping

efforts.

At the implementation stage, the major challenge is to create a system that suits the organization’s

workflow, one that will actually be adopted by users and integrated into their daily activities. The

implementation must be simple enough for employees to grasp quickly, easy enough to require only few

extra steps (or clicks), but rigorous enough to meet the organization’s overall need for record keeping within

the organization. Furthermore, any technology rollout must be manageable for the organization as a whole –

and not significantly disrupt normal business operations.

SharePoint Server 2010 includes multiple information management policy features to help an organization

manage content type as shown in Section 11.10 (c):

Document expiration

Document auditing

Document labels

Document bar codes

11.10 (k) System control

Use of appropriate controls over systems documentation including:

(1) Adequate controls over the distribution of, access to, and use of documentation for system operation

and maintenance.


(2) Revision and change control procedures to maintain an audit trail that documents time-sequenced

development and modification of systems documentation.

How Office 2010 System and Rights Management Services (RMS) Address the

Requirement

Microsoft Active Directory Rights Management Services (RMS) augments an organization’s security strategy

by providing protection of information through persistent usage polices, which remain with the information.

Content is protected with RSA 1024-bit Internet encryption and authentication so that information will be

safe in transit and will remain with the document, no matter where it goes. For example, encrypted content

stored on a lost USB drive will not be accessible and viewable to any unauthorized viewer, regardless of

location.

This information protection technology works with RMS–enabled applications to help safeguard digital

information from unauthorized use—both online and offline, inside and outside of the firewall. Record

managers and administrators can define exactly how users can use data and can place limitations on who

can open, modify, print, copy, and forward certain confidential information.

Revision and change control can be enforced through checkout and audit trail policies as discussed

previously in this document.

11.30 Controls for Open Systems

Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ

procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the

confidentiality of electronic records from the point of their creation to the point of their receipt.

Such procedures and controls shall include those identified in Section 11.10, as appropriate, and additional

measures such as document encryption and use of appropriate digital signature standards to ensure, as

necessary under the circumstances, record authenticity, integrity, and confidentiality.


SharePoint can leverage the underlying ASP.NET infrastructure to authenticate users through various means

which are discussed in Section 11.300 – Controls for Identification Codes / Passwords. Together with SSL (or

other transport level security measures), user access and data transport can be secured from the point of

creation to the point of receipt.

Office 2010 enables three use-case scenarios with the out-of-the-box digital signature functionality to

protect documents starting from their point of creation.

Authenticity & Tamper Resistance: Signing an Office document to prove that it hasn’t been

modified since it was signed. You can also view the digital certificate used to sign the document to

verify the authenticity of the document and prove that it came from a trusted individual or

organization.

Digital Signature: Signing an Office document with both a specific identity and an assertion about

why this document was signed (for example, “Approved for Publication”). This type of signature

does not print with a document and does not affect the on-page content of a document, but can

be viewed and verified with software, including Office 2010 applications.

In Document Signature: Signing an Office document in a special signature line object that visually

shows who signed the document. This feature is designed to mimic the experience of pen and ink

signatures. It is this type of signature that was created in the earlier configuration of electronic

signatures discussion.

As discussed, Office 2010 documents support digital signatures out of the box and are extensible. For digital

signature of non-office based documents, there is third-party vendor support in the market place.


In addition to the digital signature controls and SSL used to transmit the electronic record, Forefront Security

for SharePoint can provide further assurance that the record is valid by protecting Microsoft Office

SharePoint Server 2010 servers from viruses, unwanted files and inappropriate content.

11.50 Signature Manifestations

11.50 (a) Signature Manifestation

Signed electronic records shall contain information associated with the signing that clearly indicates all of

the following:

1. The printed name of the signer;

2. The date and time when the signature was executed; and

3. The meaning (such as review, approval, responsibility, or authorship) associated with the signature.


As demonstrated in the configuration example, SharePoint 2010 can use workflow to enforce document

approval and signoff. Information collected during the approval and signoff process can be customized to

include all information required under this rule and more. Custom solutions built on top of the Office

SharePoint Server 2010 can also add relevant entries to the audit log, such as when an approval workflow is

completed.

11.50 (b) Control of signature information

The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls

as for electronic records and shall be included as part of any human readable form of the electronic record

(such as electronic display or printout).


Office 2010 documents store digital signatures as a separate stream from the content stream and are part of

the document package. In compliance with XAdES, the entire signature process, including the validity of the

signature at time of signing is kept with the document package. In addition, ss shown in previous screen

shots, the digital signature of an Office 2007 document can mimic the paper and ink signature experience.

In the case of Electronic Signatures, the signature, date and time of signature, and the signature meaning are

linked to the document through metadata that is associated with the document in SharePoint; are kept with

and linked to the document throughout the document life cycle; and can be viewed with the document in

SharePoint. As demonstrated, it is possible to integrate the metadata into the body of the document, as it

would appear in a printed version of the document, through the use of a document template that reads the

metadata from SharePoint, stores the metadata in the document as part of the OpenXML, and then allows

for display of the metadata inline in the document.

11.70 Signature/Record Linking

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their

respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise

transferred to falsify an electronic record by ordinary means.



Digital signatures for Office 2010 documents are stored as part of the document. As demonstrated earlier,

Office 2010 provides a task pane to help users view and verify the signatures stored within a document. This

pane is designed to differentiate signatures based on whether they are requested, valid, or invalid. This task

pane is a built-in part of the signature platform and automatically displays information about the signature

objects regardless of whether they come from our built-in implementation or a custom written signature

add-on.

Electronic signature and approval information are stored as part of the audit trail and metadata associated

with the document. The linkage between signature and document is maintained by the server and can be

read in the document through document templates as discussed in the previous section.

Digital signature and approval information are stored as part of the audit trail and metadata associated with

the document when signed as part of a workflow.

Subpart C Electronic Signatures 11.100 General Requirements

11.100 (a) Uniqueness

Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to,

anyone else.


Policies and procedures should be developed to verify each user’s identity prior to a user being assigned a

username and password and to dictate that users should not share credentials. These policies and

procedures should be included as part of the compliance and system training process.

The creation, maintenance, and authentication of the user are discussed in Section 11.300 – Controls for

Identification Codes / Passwords.

11.100 (b) Identity Verification

Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic

signature, or any element of such electronic signature, the organization shall verify the identity of the

individual.


This should be part of the compliance solution planning and training process.

11.100 (c) Legal Certification

Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the

electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding

equivalent of traditional handwritten signatures.

1. The certification shall be submitted in paper form and signed with a traditional handwritten

signature, to the Office of Regional Operations (HFC 100), 5600 Fishers Lane, Rockville, MD 20857.


2. Persons using electronic signatures shall, upon agency request, provide additional certification or

testimony that a specific electronic signature is the legally binding equivalent of the signer's

handwritten signature.


In addition to this being part of the compliance solution planning process, a step can be added to the

signing workflow to verify that a certification check is in place (by looking at a lookup list of authorized

signers).

11.200 Electronic Signature Components and Controls

11.200 (a) Non-biometric Signatures

1. Electronic signatures that are not based upon biometrics shall:

a. Employ at least two distinct identification components such as an identification code and

password.

b. When an individual executes a series of signings during a single, continuous period of

controlled system access, the first signing shall be executed using all electronic signature

components; subsequent signings shall be executed using at least one electronic signature

component that is only executable by, and designed to be used only by, the individual.

2. When an individual executes one or more signings not performed during a single, continuous

period of controlled system access, each signing shall be executed using all of the electronic

signature components.

3. Be used only by their genuine owners; and

4. Be administered and executed to ensure that attempted use of an individual's electronic signature

by anyone other than its genuine owner requires collaboration of two or more individuals.


SharePoint supports variety of authentication mechanisms supporting 2 factor schemes (combination of user

id and password). This includes windows integrated (NTLM and Kerberos) authentication, basic

authentication, forms authentication as well as Claims Based Authentication using SAML 2.0 tokens.

11.200 (b) Biometric Signatures

Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone

other than their genuine owners.

How Microsoft Windows and Office 2010 Addresses the Requirement

There are third-party vendors who provide biometric-based authentication to the Windows system, including

most major hardware vendors. With respect to the Microsoft Office 2010 system, a biometric identity is

handled as any other identity, as the biometric information is associated with either a username or a digital

certificate. Regardless, a password is still required for authentication (in the case of electronic signatures), or

a PIN is required for authentication (in the case of a Digital Certificate).

11.300 Controls for Identification Codes/Passwords

Persons who use electronic signatures based upon the use of identification codes in combination with

passwords shall employ controls to ensure their security and integrity. Such controls shall include the

following:


11.300 (a) Uniqueness of identity

Maintaining the uniqueness of each combined identification code and password, such that no two

individuals have the same combination of identification code and password.

How Microsoft Windows and Active Directory Addresses the Requirement

This is enforced by Windows or Active Directory if using integrated authentication and Basic authentication

in an organization’s SharePoint setup.

For detailed discussion as well as a step-by-step configuration guide of windows accounts and password

policy, please refer to the articles listed in the Reference section of this paper.

For Forms authentication, this is enforced by the authentication provider.

11.300 (b) Password Policy

Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g.,

to cover such events as password aging).

How Microsoft Windows and Active Directory Addresses the Requirement

Windows and Active Directory infrastructure can enforce password policy for complexity and expiration.

Windows integrated authentication and Basic authentication can leverage this automatically.

For detailed discussion as well as a step-by-step configuration guide of windows accounts and password

policy, please refer to the articles listed in the Reference section of this paper.

A similar mechanism will need to be implemented by the authentication provider if Forms authentication is

used.

11.300 (c) Deactivation of Users

Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise

potentially compromised tokens, cards, and other devices that bear or generate identification code or

password information, and to issue temporary or permanent replacements using suitable, rigorous controls.


Windows and Active Directory administrators can deactivate users, change users passwords, or require users

to change passwords after issuing a temporary password. Windows integrated authentication and Basic

authentication can leverage this automatically.

These capabilities can be extended to Digital Signatures through Active Directory and the use of Microsoft

Active Directory Certificate Manager.

11.300 (d) Unauthorized Use of Passwords or Identification Codes

Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to

detect and report on an immediate and urgent manner any attempts at their unauthorized use to the system

security unit, and, as appropriate, to organizational management.


The Microsoft Windows family of products, including Microsoft Windows Server 200 R2 and Windows 7 can

both audit logon changes and failed attempts.


Group policy can enforce account lockout policy to help to prevent brute force password guessing. Lockout

policy is based on failed attempts for a time window and users can be locked out for specified times before

they can attempt again (or not).

Group policy can also enforce password policy to mitigate the risk of unauthorized credential use. Password

policy can be set to enforce complexity of the password (including minimal length and combinations),

password aging (expiration), and password history (reuse of previous passwords).

Similar policies can be extended to Digital Certificates through the use of Microsoft Active Directory

Certificate Services.

11.300 (e) Identification Code Device Testing

Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or

password information to ensure that they function properly and have not been altered in an unauthorized

manner.


This should be part of the operational procedure that is written into the compliance policies and procedures.


Systems Validation and

Compliance Systems validation and compliance is covered in depth in a Microsoft whitepaper entitled “Validation and

the Microsoft Platform.”

The whitepaper covers the following topics:

Microsoft software development practices and how they map to the industry v-model

Installation Qualification methodology using Microsoft tools and system resources

Operational Qualification methodology using Microsoft tools and system resources

This whitepaper is available on MSDN at the Microsoft Life Sciences Developer Center

(http://msdn.microsoft.com/architecture/lifesciences

The information contained in this document represents the current view of Microsoft Corporation on the issues

discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should

not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of

any information presented after the date of publication.

This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this

document.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under

copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any

purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights

covering subject matter in this document. Except as expressly provided in any written license agreement from

Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights,

or other intellectual property.

© 2012 Microsoft Corporation. All rights reserved.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and

events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-

mail address, logo, person, place, or event is intended or should be inferred.

Microsoft, Microsoft Office 2010, Microsoft SharePoint 2010, Microsoft Word, Microsoft Excel, Microsoft

PowerPoint, Microsoft Rights Management Services, Active Directory, Windows Server 2008 R2, Windows 7,

Windows Vista, Windows XP, Microsoft Windows, Microsoft Certificate Lifecycle Manager, Microsoft Visual Studio,

Microsoft Forefront are either registered trademarks or trademarks of Microsoft Corporation in the United States

and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

http://msdn.microsoft.com/architecture/lifesciences