Security in SharePoint for the Business Analyst

Category: SharePoint

As of a part of SharePoint Business Analyst series (which is a part of my book, The SharePoint Business Analyst Guide), I wanted to review many of the different types of requirement documents I use on my projects. Each project will require a different set of documents depending on the complexity, people involved, budget, stakeholders, etc.

I have often been asked at conferences “How do I make sure my SharePoint application is secure?” or “How do I get the administrators or infosec team to sign off on the requirement documents regarding security?”. Unfortunately, there is no easy answer to this question. Security is never 100% guaranteed no matter how much effort and cost you put into it. However, your goal should be making the SharePoint application you are working on as secure as possible. In my book, I have broken things out into three sections regarding where security begins and can be an open hole you will need to address. See these items below:

  1. Built-In Features & Services in the SharePoint & Office 365 to Enable and Configure
  2. SharePoint site collection level (and below) configuration regarding security
  3. Human behavior, compliance, and governance regarding security

Built-In Features & Services Microsoft Gives You in the SharePoint & Office 365 to Enable and Configure

  • IRM – You can use Information Rights Management (IRM) to help control and protect files that are downloaded from lists or libraries.
    Example of enabling IRM at the tenant level in the SharePoint administration center in Office 365.
  • DLP Use data loss prevention (DLP) policies to help identify and protect your organization’s sensitive information.
    Azure Rights Management allows you to encrypt each file and must be opened using a client that supports Azure Rights Management such as Microsoft Office.
  • Auditing – Auditing is not a tool to restrict access. It is a monitoring feature to create an audit trail for content and user activity.
  • Two-Factor Authentication -it basically means your users will have to authenticate twice to access content. This is a once per session activity.
    Microsoft has an app to download titled Microsoft Authenticator app and is available for download for iOS and Android.
  • MDM Another option for Office 365 (and possibly InTune) is Mobile Device Management.
  • HTML Field Security – This is a simple feature that basically allows or disallows users to embed iFrames on SharePoint

Human Behavior, Compliance, and Governance Regarding Security

If you do not live in Europe and do not do any business with anyone in Europe, you get a free pass to skip this section! If you fall into either category, unfortunately, you will have to work this into your project considerations. According to the Compliancy Group, SharePoint Online is HIPPA compliant. I have included more links regarding this on my addendum page on my website.

If Custom Development Has Been Performed

When development has to occur in your project, there are additional security factors to consider. Since a human performs the programming, how the developer chooses to program SharePoint will determine if it is secure or not. Using JavaScript & CSS to hide items in SharePoint is not truly secure. With full-trust solutions, there is risk here is that developer could program almost anything they want. Think of this as the developer having the “keys to the kingdom”. It is important to be aware that your developer also contributes to the security factor of your SharePoint application.

External Users & External Sharing

You can share a specific item in SharePoint via the Share a Link option At the moment, you need to have some type of Microsoft account (Outlook, or Office 365) to accept a sharing request as the external user. The important factor to understand here is that once again, a human can share something that they shouldn’t and this affects the security of the site. Make sure to investigate the tenant wide sharing settings if this important to you.

Assigning and Architecting Permissions at the Site Collection, Site, List/Library & Item Level

First it is important to understand, from the site collection level and below, what SharePoint already has to offer. You can restrict or control access at:
• The top site collection level
• The sub-site(s) below (within) the site collection
• The library or list itself
• Each document or item within a list or library
Next you need to decide how to group your stakeholders and users of the SharePoint site to assign security. This will depend on if you are going to use:
• Active Directory groups (which may or may not already be created or be able to be created by your Windows Administrator)
• Create SharePoint groups within the site
• Use Groups in Office 365 (Which some people are referring to as o365 Groups)
• Assign users individually a permission

In my book, I go into the pros and cons of using which type of permission assignments so you can make the best decision for your project.automated approval email can be sent to the group’s owner.

Planning Properly to Assign Permissions & Permission Levels

As a part of security planning, there is a section in my SharePoint “Conversation Starter” Requirements Questionnaire document that asks for all of the different roles your site will need (this is available in my book). For example, you may have a couple of managers, some editors and many authors. This would be a total of 3 roles which should equal 3 groups of whatever type you choose. You can then put the appropriate people in each group and assign a permission level to that group.

Other Human Errors That Can Create Security Issues

  • Someone with full control or farm level administrator privileges who decides to “go rogue”. Unfortunately, this is a human trust behavior and unless you have 2 people watching each other at all times or have disabled all email, screen shot, and USB drive abilities to share items there isn’t much one can do about it.
  • Someone with full control who decides to give others full control who haven’t been formally trained. I have seen people giving access to people they shouldn’t have, accidentally delete things, break things, you name it. Full control should be used sparingly. If possible when creating a new site collection for your users, you could create them as I saw at one of my clients where they were created from a custom template that has the ability to add other users with full control to the site access. This is one way to avoid this issue from occurring.
  • Someone creating a script that needs a password and leaving the password unencrypted in the script or in a text file on the server. This was the cause of the Sony breach a few years back.



Wow, we sure covered a lot regarding security in SharePoint and its correlating technologies! As mentioned earlier, this can be very overwhelming. You may need to consult external or internal help with some of this. But remember, each area is a specific security concern which is a part of the entire concept of making SharePoint secure. There is no way to guarantee anything is truly 100% secure. You can only use as many of the tools and best practices available to make your SharePoint site as secure as possible. Also remember I go into more detail regarding this in my book if you are interested. Either way, make sure that if security matters in your application you take the time to review all of these items!

(Visited 1 times, 2 visits today)
2.5/5 (2)

Please rate this blog post!


Leave a Reply

Your email address will not be published.