Microsoft SharePoint is used in many highly secure environments around the world that deal very sensitive information – information that is considered ’secret’ or ‘top secret’ and where security of that data is critical to not only business but also to national security. These deployments exist primarily in military and government installations, or as part of the intelligence community. In these SharePoint deployments, its extremely important that security and access control policies be configured in such a way that they “Fail Safe”.

The concept of “Failing Safe” means that if the security system which implements the access control policies fails, for whatever reason, that sensitive information will automatically have the most restrictive access rights automatically applied. Therefore, in these cases, if such a system failure occurs then the sensitive information that is being protected is not left open and in the clear, allowing non-authorized users to access it.

Examples of an access control policy system failing could be an authorization server going down, it could be an inadvertent reboot of a server, or it could even be an unauthorized user gaining access to the environment and interrupting communication between the authorization system and the content management system (SharePoint). There are many such examples. Hardening critical infrastructure and protecting it against all possible forms of attack or circumstances that might arise is a very difficult task that must be performed. However, you also want to ensure that you look at this problem from the point of view of: if all else fails, then access to my sensitive information will revert back to the most restrictive access rights possible so that my sensitive data is not inadvertently released.

TITUS Metadata Security for SharePoint uses trusted claims about a user, and combines them with document metadata to ensure that the right people are accessing the right information in SharePoint. TITUS Metadata Security automatically applies fine grained access control to SharePoint content using the SharePoint permissions system. This has the advantage of enforcing the access control policies that administrators or site owners configure on all the mechanisms that information workers can use to access content within SharePoint, including the SharePoint web view, the explorer view, search, FAST search, the client object model, the server object model and any web services that may be deployed. With TITUS Metadata Security, policies are dynamically enforced, so that as a user’s identity changes or as metadata changes, security policies are automatically applied and user’s are only accessing the content they are permitted to access.

TITUS allows you to set the default permissions on all content within SharePoint to the most restrictive access rights possible. Then when defining access control policies and enforcing those policies with TITUS Metadata Security, TITUS will simply add the appropriate access rights for specific users, groups, or users with specific claims to only gain access to sensitive content that they are permitted to access . This allows Microsoft SharePoint to “Fail Safe” so that if a malicious user or a failure in process subverts the access control policy system, that your sensitive information will revert back to its default inherited SharePoint permissions (the most restrictive access rights possible) and still remain secure!

There are several other systems on the market which implement access control policies or entitlement management in Microsoft SharePoint. However, these systems often require that default permissions on all content be initially configured to the most open access rights possible. The issue here becomes that if that access control system were to be subverted or fail, for whatever reason, and if SharePoint then reverts back to its default inherited permissions then all content including your most sensitive content will be inadvertently leaked. TITUS Metadata Security for SharePoint is the only leading fine grained security system for Microsoft SharePoint that allows SharePoint to”Fail Safe”.

TITUS Metadata Security for SharePoint allows organizations to leverage all of the benefits of user claims and document metadata to secure their sensitive information in SharePoint. It ensures that the right people are accessing the right information and it allows Microsoft SharePoint to implement Fail Safe Security so that sensitive information remains secure in all circumstances.

-Antonio

Previously, we’ve talked about how using trusted attributes of a user’s identity (or claims) along with document metadata is a very robust way of enforcing security policies within Microsoft SharePoint 2010. This article reviews another important tool that can be used to configure security policies for SharePoint:  Claim Rules.

In general, claim rules can be used to centrally evaluate, transform or augment claims before they are returned to a relying party application like SharePoint. Microsoft Active Directory Federation Services version 2.0 (ADFSv2) can act as a trusted identity provider to SharePoint and other relying party apps.  It provides a great interface with templates for creating and editing claim rules as part of its management console.  As well, it provides a ‘claim rule language’ that can be used to configure detailed policies with very specific conditions. This allows us to configure specific claims to be retrieved under very specific conditions, and thereby enforce very specific security policies for authentication and authorization.

This series of articles talks in detail about how to use this mechanism to enforce dynamic access control policies within SharePoint 2010 and, it illustrates how these policies relate to particular industries and regulations in SharePoint.

This article assumes an in-depth level of knowledge related to configuring SharePoint with Claims Based Authentication using ADFSv2.  For additional background on these topics please see the following article: An Architecture for Claims Based Authorization in SharePoint.

SharePoint 2010 can be configured to connect to a trusted identity provider like ADFSv2 to authenticate a user at sign-in time.  This is called Claims Based Authentication.  Under such a configuration, when a user signs into SharePoint, it will communicate with ADFSv2 passing it the user’s credentials.  ADFSv2 will then authenticate the user against Active Directory.  Before this happens, ADFSv2 will have been configured to trust the SharePoint 2010 server (the relying party) that is connecting and, as part of that trust relationship, ADFSv2 will have also been configured with 1 or more claim rules.  After the user is authenticated, ADFSv2 will apply the configured claim rules to the incoming claims in order to transform or augment them before they are issued and returned to SharePoint.

Configuring Claim Rules

ADFSv2 can be configured to accept incoming claims as well as issue outgoing claims.  In either case, trust needs to be configured between ADFSv2 and the calling app.  For incoming claims, the trust relationship in the ADFSv2 management console is referred to as the “Claims Provider Trust”.  For outgoing claims, or claims that ADFSv2 issues to a relying party, the trust relationship is referred to as the “Relying Party Trust”.  The important point here is that claim rules are configured as properties of these “trusts”.

ADFSv2 Management Console

ADFSv2 can be configured with one or more trusts (one for each calling application), and each trust can have one or more claim rules. When configuring a trust for SharePoint, you will need to provide the realm of the SharePoint server. ADFSv2 will use the realm passed to it in order to map a particular request to a particular trust that’s been configured.  For more information on configuring the realm, see the following:  Configuring the Realm for SharePoint 2010 and ADFSv2 to Retrieve Claims.

Once the trust is configured for the particular SharePoint server, to create a claim rule for that trust, perform the following steps:

• In the ADFSv2 Management Console, click Relying Party Trusts in the tree at the left side
• Right click on the particular trust which pertains to the SharePoint server you’re working with
• Click the Edit Claim Rules menu
• Ensure that you have the Issuance Transform Rules tab selected (the first tab)
• Click the Add Rule button and follow the instructions in the wizard – it is quite easy to use
• Keep in mind that the claim rules will be executed in the order listed. This can be important, especially if you have one claim rule acting on the claims issued by another rule. You can use the arrows on the right side of the Edit Claim rule window to change the order and get the desired output.

Once you’ve configure a set of claim rules for a particular trust, unfortunately they cannot be reused on another trust. If you must reuse the same claim rule(s) with more than one trust, you’ll need to manually recreate them. We’re focusing on enforcing security policies within SharePoint, so this particular article will focus only on claim rules configured for a Relying Party Trust which issues outgoing claims to SharePoint. From this point forward, the article will refer to SharePoint as the relying party, but please keep in mind that any relying party can be configured and used with the same types of claim rules.

Again, when a user signs into SharePoint, SharePoint will call its configured trusted identity provider, ADFSv2 in this case, and ADFSv2 will authenticate the user against its directory or database. Then ADFSv2 will execute the claim rules that have been configured with the particular trust for the calling SharePoint server. These particular claim rules will be used to determine which attributes are ultimately issued to (ie. returned) to SharePoint.

Claim Rule Templates

Claim rules will be used to determine which attributes are ultimately issued as outgoing claims (ie. returned) to SharePoint. These rules can be quite simple – for example, they can simply retrieve specific LDAP attributes from Active Directory and return them to the connecting SharePoint server as SAML claims. They can also be more complex, and we’ll see some examples of that later. The ADFSv2 management console provides 4 templates and an easy to use wizard for configuring rules. For many security policies, these templates are quite sufficient for achieving a policy’s intended purpose. These templates are:

1. Send LDAP Attributes as Claims

• Probably the simplest type of rule, it can be used to retrieve user attributes from an LDAP directory and issue them as outgoing claims to SharePoint.
• It can be used to perform a simple mapping of attributes if required, from an LDAP attribute name to perhaps a different name (or claim type) that SharePoint is expecting. For example, a claim rule could retrieve the standard LDAP attribute ‘organizationStatus’ and map it to the claim type ‘EmployeeStatus’ if that’s more appropriate for the intended user experience within SharePoint.
• Multiple claims can be retrieved or mapped with a single rule.
• Performance can be somewhat affected by this type of claim rule due to the account look up that must occur. However, for all practical purposes the performance impact appears to be minimal for each individual request.

2. Send Group Membership as a Claim

• This claim rule will check to determine if the user is a member of a specific AD group and if so, it will issue a specified claim with a specified value. This can be very helpful if you already have security groups in place and want to leverage them to enforce claims based authorization policies in SharePoint.
• The unfortunate thing about this template is that each rule will only check membership to 1 group. You can create multiple instances of this type of rule for the same trust, and within each rule check membership to a different group so that a particular claim is issued in each case. However, if you want to enforce policies where a user must belong to multiple groups in order to access content within SharePoint, then a more sophisticated solution is needed – Please see Part 3 of this blog series for an example of how to accomplish this with the Claim rule Language.
• As well, this claim rule does not support SharePoint groups, only Active Directory groups. To check membership to SharePoint groups, you must create a custom claims provider that runs on your SharePoint server… but that is for another day.
• One positive thing about this rule template is that it is very fast to execute. The reason is that one of the default claims that ADFSv2 retrieves is the list of all groups SIDs that a user belongs to. ADFSv2 does not need to do any additional account look up.
• This rule can only be used for users that authenticate locally using AD DS (Active Directory Domain Services) and come through ADFSv2 through the Active Directory Claims Provider Trust.

3. Transform an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can apply various actions to transform the type or value before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued with the same type and value.
• Another option is to modify the type of the claim before it is issued as an outgoing claim. So, for example, an incoming claim could be of type “OrgStatus” and this rule could be used to issue it as the outgoing claim type “Status”, keeping its current value. Another incoming claim in the same environment could be of type “OrganizationStatus” and a similar rule could issue it as the outgoing claim type “Status”, again keeping its current value. This type of rule can help to normalize claim types when they are coming from various sources and perhaps have differing claim type names, but all mean the same thing.
• Additional options in this rule template allow you to modify the value of the claim before it is issued. The following options are available:
  • If the value of an incoming claim equals a specified value, then change its value to a new specified value before issuing the outgoing claim. There are no StartsWith, EndsWith or Contains-like options available here. More complex value checking requires a custom claim rule – see Part 2 of this blog series.
  • If an incoming claim contains an email suffix, then replace it with a specified email suffix.

4. Pass Through or Filter an Incoming Claim

• This claim rule compares the type of an incoming claim to a selected type. Depending on its type, it can optionally apply other filters before issuing the outgoing claim to be returned to SharePoint.
• If the incoming claim matches the selected type, one option when configuring this rule is to simply pass it through and have it issued.
• Another option is to filter it based on certain values. The following options are available for filtering:
  • Only issue the claim if its value equals a specified value – for example, if an incoming claim is of type ‘EmployeeStatus’ and if its value is ‘Full Time’. The claim is issued only if both conditions are met.
  • Only issue the claim if it is an email address and if it ends in a particular value – for example, check if the claim type is E-Mail Address, and if so issue it only if the email suffix is ‘titus.com’ or some partner email domain.
  • Only issue the claim if its value starts with a particular string – for example, check if the claim type is Department and if its value starts with certain department acronym.
• Claim values cannot be changed with this type of rule. They must either be issued or not based on their type and value.
• This rule can apply to claims that have been issued by previous rules. One interesting use for this type of rule is if certain claim types contain sensitive information and you do not want that information to be issued to certain relying parties. The issuing of certain outgoing claims can then be restricted based on their values.

Once a user has signed in and their claims are retrieved, SharePoint 2010 does a great job of enforcing permissions on documents and items to which claims have been assigned with a permission level. Of course a user must have those claims as part of their identity to gain access to a document or item with the assigned permission level. Centrally managing how claims are retrieve and returned through ADFSv2 claim rules can allow you to implement some very robust access control policies in SharePoint. Applying those claims with permission levels to documents and items in SharePoint is still a manual and labor intensive task that can be very error prone – for more information on how the TITUS SharePoint Security Suite can automatically assign such access control policies at a fine grained level in SharePoint please read the white paper Microsoft SharePoint Security – Harness the power of claims to protect information or check out the video.

Once again, for many security policies these rule templates are sufficient for achieving a policy’s intended purpose. If more sophisticated policies are required, ADFSv2 does provide a Claim Rule Language that can be used to author detailed policies with very specific conditions. Please see Part 2 of this blog series in order to learn more about how to use the Claim Rule Language.

-Antonio

I got quite a few questions and request for copies of my slides for the presentation I did a few weeks ago at the Microsoft SharePoint Conference 2011 in Los Angeles.   The presentation was called Using Claims for Authorization in SharePoint 2010. For an explanation of how claims can be used for authorization (deciding what documents or items users are allowed to see) in SharePoint click on this link to download my presentation. The PowerPoint has been converted to PDF format.

I have also started a blog series on Claims in SharePoint and here is my first post What are Claims – Using Claims in SharePoint.

Antonio

Hello from the Microsoft SharePoint Conference 2011 in Anaheim CA.

Many enterprises use Microsoft SharePoint for Records Management.  Despite how much has been written on this, Records Management is sometimes confused with Document or Content Management , but it’s in fact quite a unique discipline with its own best practices and processes. Microsoft SharePoint 2010 provides some great features to enable these processes, and it provides enterprises with the appropriate controls over the data and documents that they declare to be corporate records.  Here at the Microsoft SharePoint Conference, Records Management figures pretty prominently among several of the sessions.  There’s lots to learn here about managing records and I’m going to review some of that in this post.

Introduction to Records

To start things off, a record refers to a document or some other piece of data in an enterprise  (electronic or physical) that provides evidence of a transaction or activity taking place, or some corporate decision that was made.  A record requires that it be retained by the organization for some period of time.  This is often a legal or regulatory compliance requirement.  As well, a record by definition must be immutable, which means that once a document or piece of data is declared to be a record, it must remain unchanged.

These requirements for records immediately suggest certain processes that must be in place to ensure that they’re managed appropriately from several perspectives:  business , auditing/legal , tax, revenue , and even business continuity.  As we often find, for business processes to be applied consistently across all SharePoint content or records, automation is a key requirement, as well as making appropriate use of metadata.

Working with Records in Microsoft SharePoint

Declaring Records and Retention

First, its important to determine what type of content should be considered a record.  For example, if I’m working on my department’s budget for next year, my initial draft and its various iterations should likely not be considered records because they are still changing – they are not yet approved, nor are they final, nor can I make any decisions based on those preliminary versions.  But once my budget is ‘approved’ or considered ‘final’ then it can be declared a record because I can now base corporate decisions on it.  Establishing a policy around what type of data is a record requires planning, meeting with appropriate stakeholders and agreeing on policy that’s communicated to everyone that may be declaring content as a record.

Next, its important to assign a retention period to records.  The period for which records are retained, along with the process followed once that time period has expired, is a critical requirement for records management.  There are legal and business implications to consider when content is kept content too long.  The business policy could be that after X years, a record is archived and then after Y years from that point it is disposed (which could include deletion or moving it to offline long-term storage).  Again, establishing this policy requires planning and getting agreement from stakeholders, especially around any legal, regulatory compliance, revenue or tax implications.

Records Management Features

Once that policy is in place, Microsoft SharePoint provides several features to enable users and/or automated processes to actually declare content to be a record:

1. Records Center Site

The records center site is essentially a SharePoint site dedicated to centrally storing and managing records.  SharePoint 2010 still has the Record Center Site template from MOSS2007, but it now provides integration with several new very useful features including:

• A dashboard view at the site level for Records Managers with searching capabilities
• Integration with the Content Organizer for routing records within the site
• Document ID service to assign a unique identifier to documents which travels with it
• Email Integration with the Content Organizer
• Legal Holds
• Metadata Navigation/Filtering

Depending on the business need, it may make sense to centralize records management and storage in this way.  If the business demands that a small number users be considered ‘Record Managers’ and its their role alone to declare content as records then it may make sense to follow this approach and make use of the Record Center Site.

2. In-Place Records Management

This feature allows individual users to declare documents/content as records while they reside in their current location.  In using this feature, records do not need to be moved or added to a central Record Center site, nor do they need to be routed within the Record Center.  This is a trend in the records management space, because it allows users to continue find content where it resides, based on its business nature or properties.

In-place records management is not enabled by default, and you need to activate the feature at the Site Collection level.  You can also configure various options like:

• Restrictions imposed on in-place records:  Block Delete, Block Delete and Editing
• Availability of In-Place Records Declaration – if this feature is turn on, then Declare Record and Undeclare Record buttons appear in the ribbon bar for end users; if turned off, then records can still be declared in place but only by workflows or retention policies
• Declaration Roles – specifies the types of users that can declare and undeclare records; the options here are: all list contributors and administrators (any users with the edit items permission), only list administrators, only policy actions (only policies or custom code running as System Account can declare/undeclare records)

Once configured, it will be available for all sites and libraries throughout the site collection.  You can then restrict access to it on individual libraries and lists by configuring their settings in Library/List Settings.

The other great features mentioned for the Record Center Site are also available for In-Place Records management.

This type of in-place records declaration and the settings mentioned suggests that other individuals be enabled to make the decisions about declaring and undeclaring records.  Depending on the business need, enabling a broader range of end users to declare content as records may or may not make sense.  You tend to find that individual employees, those not typically designated as records managers, can be nervous or apprehensive about declaring content to be records for the enterprise because it implies a level of official accountability or legal declaration over that content.  So, there are some ways to make this simpler using some automated retention policies and metadata.

3. Retention Policies and Workflows

Retention Policies and Workflows in SharePoint can be used to automatically declare documents as records after a certain time period or based on certain metadata values.

Retention Policy

A retention policy can be configured so that certain actions are taken on documents after a certain period of time.  For example, a Retention Policy could be configured so that if a document has not been modified for 2 years it can then automatically be declared a record and moved to the Record Center Site.  Retention policies can also be multi-staged so that, for example:

• After a document has not been modified for a year then all previous versions of the document are deleted
• After a document has not been modified for 2 years then it is declared a record
• After it has been a record for 7 years it is automatically disposed

Retention policies can even be configured for non-records (active documents) and used to delete or dispose of outdated or expired content after certain periods of time.  In the same site or library you can have different policies for records than for non-records.

Retention Policies can be configured for a number of different circumstances:

• For content types and applied to all instances in the site collection
• For content types at the site level and applied to all instances in the site
• For individual libraries, lists or folders

There is some very good instructions found here on how to configure these policies:  http://office.microsoft.com/en-us/sharepoint-server-help/create-and-apply-information-management-policies-HA101631505.aspx

Workflows

Workflows are a very useful and widely used feature of SharePoint.  They are used to enable many different business processes across thousands of SharePoint deployments.  Some great things you can do when creating a workflow are:

• Configure it to send a document or item to another site
• Configure it with conditions so that it is triggered only when certain metadata fields are equal to specified values
• Configure it with additional actions like emailing users

By combining this condition with these actions, you can create workflows that will automatically trigger when a Status metadata column is set to ‘Final’ by an end user.  This can then cause the workflow to automatically send the document to the Records Center Site (causing it to become a record) and send an email to the Records Manager to approve the declaration of the record.  In addition, this and other workflows (that perhaps don’t involve metadata) could be triggered by a Retention Policy so that these actions automatically occur after a certain amount of time has passed.

What you accomplish with this type of configuration is that you’ve removed the need and any apprehension for end users to officially declare records.  You’ve also used metadata to determine when active documents are ready to automatically become records.  You’ve sent a notification to the Records Manager so that they are aware and can provide any approval if needed.  And finally, you’ve dealt with abandoned items where metadata is not updated  but the document can still become a record if needed.

Due in part to the rate at which content is growing in SharePoint, its easy to see why using automation to declare and manage records is a recommended strategy for consistently applying policies across your farm.

Security Implications

There are some security implications that you need to think about if you are taking sensitive content in SharePoint and declaring it as a record.  For example, if you are using the Record Center Site and a sensitive document with very specific item level permissions is declared a record it may be automatically moved to the Record Center, however its permissions will not be moved with it.  It will inherit permissions from the destination library within the Record Center.  This can be especially problematic if you have a very active Record Center which users refer to often

TITUS Metadata Security for SharePoint can automatically apply permissions to sensitive content in SharePoint, even within the Records Center Site.  It can ensure that specific item-level permissions are maintained on content when it is active, and after it has been declared a record.  It does this by using metadata to determine the security permissions that must be applied – the same metadata that can be used to trigger records management policies.

With In-Place Records Management, SharePoint can display a lock icon beside a document once it is declared a record.   This is a great feature which lets users know that they’re looking at or working with a record.  However, if the document is saved locally, emailed or used in other circumstances it can be difficult for end users to realize that they are working with an official corporate record.  Its important to ensure that end users are aware of when they’re dealing with official records.

TITUS Document Policy Manager for SharePoint can automatically apply visual labels to Microsoft Office and PDF documents in order to raise awareness about when end-users are dealing with official corporate records.  These labels take the form of headers, footers and watermarks within the document, so they travel with the record.  As well, they are completely configurable and make use of document metadata, so they can be formatted to conform to corporate document templates.  Finally, they can include security labels, information about the retention policy for the record and include disclaimers about how the record can be distributed.

To Sum Up…

Microsoft SharePoint can be used as a full-featured robust Records Management system.  It contains some great features that can be used to define the appropriate records and retention policies for the business.  Its key to use automation and leverage metadata to ensure that records management policies are applied consistently across all your SharePoint content.

Its also important to understand the security implications and ensure that records, like all sensitive content in SharePoint, have the appropriate permissions and the appropriate visual labels.  TITUS Security Suite for SharePoint can help automate these processes , so that end users only access the records they are permitted to access, and so that they understands what is a record and how to handle it.

-Antonio

I read a great article recently on the benefits of using Metadata in SharePoint that I wanted to share. Its written by Michal Pisarek and can be found here: The Battle for Metadata in SharePoint 2010.

Whether government or military personnel are classifying documents, or whether people at home are sorting through digital music, metadata is becoming a fundamental part of our work and home lives. Within SharePoint itself, metadata is put front and center as an intrinsic component of the entire system. This article talks about how people have already been working with metadata for years, and how it can solve real business issues in SharePoint.

There are some things in life that just don’t seem to go together.

America and Soccer.

These two things don’t go together…or do they?  In the past, soccer has never been a first-class citizen in the world of American sports.  Even though soccer is the most popular sport in the world (based on number of fans), it is not even in the top ten most popular sports in America.  Despite these statistics, if you think back a few weeks, in a flurry of attention and fanfare, the 2011 US Women’s National soccer team made American history in their world championship game.  Not because they won (because they didn’t), but because they made Americans realize how much they valued the game of soccer.  Their game drew over 14 million American viewers, making it the second-most-watched women’s game in US television history, and ESPN’s most-watched and highest-rated soccer game ever.

Governance and Collaboration.

These two things don’t go together…or do they?  At first thought, these things seem completely opposite, and would almost hinder each other.  Both are very important in organizations, but both are very different concepts.  Governance has to do with disciplined handling of information with the goal of properly controlling that information.  Collaboration is about sharing knowledge without boundaries with the goal of freely sharing information with the right people.  In today’s organizations, information is exploding, and collaboration is becoming more and more mainstream.  Because of this explosion of information, governance on this information not only enhances collaboration, but has become a crucial component of a successful and secure collaborative environment.  In order for users to freely and successfully share information with each other, a comprehensive, high level data governance model must be put in place.  It could be said that the explosion information within collaborative environments has made organizations realize how much they need and value data governance.

Microsoft SharePoint is the world leader in enterprise collaboration and content management.  SharePoint is Microsoft’s fastest revenue growth product in company history, even faster than Windows and Office!  Mirroring this growth is the growth of information within each SharePoint environment.  Many of our customers express that their collaboration sites are quickly growing to a point where they are out of control.  SharePoint administrators, and subsequently SharePoint users, cannot properly control the information being shared, stored, and collaborated on within SharePoint.

Increased concerns regarding corporate accountability and compliance, as well as efficiency, are driving the need for organizations to maintain a consistent data governance policy.  The recent high-profile case of a Massachusetts hospital healthcare worker mishandling a sensitive document (resulting in a $1 Million penalty) is just another example that illustrates the need for data governance within organizations.

For proper data governance within SharePoint, organizations must put into place a set of processes, activities and procedures for ensuring that important data assets are formally managed throughout the enterprise, and throughout their lifecycles.  There are 8 steps to creating an effective data governance model for SharePoint:

1. Define Roles/Policies and Stakeholder Agreements
2. Apply Security Settings
3. Enforce Document Creation Rules
4. Control Access
5. Raise Awareness of Data Sensitivity
6. Promote End-User Accountability
7. Manage and Log Document Lifecycle Events
8. Audit and Report

For more details on these steps for how to successfully implement a data governance model within SharePoint, I urge you to read our whitepaper.  Please visit www.TITUS.com/software/sharepoint/ to learn how the TITUS family of products can introduce data governance to your SharePoint environment.  TITUS products automate technical security controls through consistent, automated enforcement of metadata generation, document conversion to PDF, and labelling of documents.