I've always advocated that SharePoint inherittance should be broken in the following order; site collection, site, library, document set, folder, document. In other words only break at document level as a last resort. Logically the smaller number of permissions groups then the easier this is to manage and also this will encourage better collaboration and make it easier for users to find relevant information (SharePoint is not called LockdownPoint). Does anyone know if there is some good online advice around this? A good tutorial or video that I can share with my user community? All I can find is step-by-step guides on how to break inherittance rather than advice on when to break inherittance.

I've always advocated that SharePoint inherittance should be broken in the following order; site collection, site, library, document set, folder, document. In other words only break at document level as a last resort. Logically the smaller number of permissions groups then the easier this is to manage and also this will encourage better collaboration and make it easier for users to find relevant information (SharePoint is not called LockdownPoint). Does anyone know if there is some good online advice around this? A good tutorial or video that I can share with my user community? All I can find is step-by-step guides on how to break inherittance rather than advice on when to break inherittance.

So this has been a loaded question and one that got worse when Microsoft provided the Share functionality in SP2013.  It has always been the best practice to control access via AD groups so the ACL in the index isn't constantly being updated and slowing down response in the crawl and in displaying data via security trimming.  However, that all went out the window when Microsoft provided users the ability to share documents, folders, lists, and sites in SharePoint 2013.

I still strongly support that document level inheritance breaking should not be done.  It becomes an administration nightmare and if done extensivily a performance affecting issue.  Because of the Share buttons, to stop this from happening you either have to do some extensive custom development or implement a tool that blocks this process (I believe AvePoint and Metalogix support this).

From an admin stand-point I try to influence my clients to ask the question \"Why don't you need access?\" instead of the normal \"Why do you need access?\"  This means you can open things up at the top level and only lock them down if the content warrants it.  At my current client we have a document that defines when a document should be restricted or not.  This helps in controlling the access and setting up an easy to use security system.

So in my opinion never actively lock down documents as a SharePoint admin.  The lowest you should go is a folder.  If you can get away with it don't lock down an entire list\\library and even leave the site open unless the entire site contains securable information within it.  If you are worried about users going snooping through data they don't need to, then your users need more work assigned to them.  It's a simplistic way of looking at it, but in my opinion you need to stop considering how best to lock down your data internally and instead keep the Share in SharePoint and lock it down as little as possible.  It requires a mindset change in many locations, but in the end users will be able to collaborate, search and work together much easier then when your SharePoint environment resembles a document prison.

So this has been a loaded question and one that got worse when Microsoft provided the Share functionality in SP2013.  It has always been the best practice to control access via AD groups so the ACL in the index isn't constantly being updated and slowing down response in the crawl and in displaying data via security trimming.  However, that all went out the window when Microsoft provided users the ability to share documents, folders, lists, and sites in SharePoint 2013.

I still strongly support that document level inheritance breaking should not be done.  It becomes an administration nightmare and if done extensivily a performance affecting issue.  Because of the Share buttons, to stop this from happening you either have to do some extensive custom development or implement a tool that blocks this process (I believe AvePoint and Metalogix support this).

From an admin stand-point I try to influence my clients to ask the question \"Why don't you need access?\" instead of the normal \"Why do you need access?\"  This means you can open things up at the top level and only lock them down if the content warrants it.  At my current client we have a document that defines when a document should be restricted or not.  This helps in controlling the access and setting up an easy to use security system.

So in my opinion never actively lock down documents as a SharePoint admin.  The lowest you should go is a folder.  If you can get away with it don't lock down an entire list\\library and even leave the site open unless the entire site contains securable information within it.  If you are worried about users going snooping through data they don't need to, then your users need more work assigned to them.  It's a simplistic way of looking at it, but in my opinion you need to stop considering how best to lock down your data internally and instead keep the Share in SharePoint and lock it down as little as possible.  It requires a mindset change in many locations, but in the end users will be able to collaborate, search and work together much easier then when your SharePoint environment resembles a document prison.

I agree with you. Share Button is administrator's nightmare. It's difficult to understand the Microsoft policy and recommandation to don't break inheritance when then promote the share functionality. In fact, the share funtionality is a break of inheritance rights...