33 Replies Latest reply on Aug 29, 2013 2:01 PM by cflanagan17

    Best practice sharing: contractor access to internal employee communities?


      We deployed Jive a few months ago as an internal collaboration tool. It would be great to get some benchmark information / best practices from other companies regarding "non employee" or contractor access to your internal communities. I am mainly interested in how you found the balance between openly sharing information to enable collaboration across the whole user base and locking down critical information to a subset of users to avoid the loss of intellectual property. We currently restrict access to employees only and have mostly open groups to encourage collaboration, we would like to include contractors in the future though ...


      1. Do you allow contractor access to your employee community?
      2. If yes, what processes or policies do you have in place (if any) to mitigate risk of IP loss?
      3. If yes, do you allow all contractors or an approved sub-set? Where did you draw the lines?
      4. If no, why not? And how do you ensure contractors gain access to content / materials they need to collaborate on?
      5. Please provide some context/demographics if possible: What industry are you in? How many employees do you have? If you were to guess, how many contractors do you have (or what % of your employee base?)


      Thank you!

        • Re: Bet practice sharing: contractor access to internal employee communities?
          Dennis Pearce

          Our Jive environment is synchronized with our LDAP (identity management system) to allow single sign on, so any contractors who have company userids (i.e., xyz@lexmark.com) can access our internal community.  All of our employees sign a code of conduct statement annually, and all of our contractors sign a similar non-disclosure agreement, so from a risk mitigation standpoint we view them the same as we do employees.  We don't allow access by contractors who do not have Lexmark userids.


          We have an assortment of open and closed groups and spaces, so it is up to the admin of each restricted place to decide which people, employees or non-employees, should have access to that information.  If they are able to log into Jive, we don't really make any distinction between employees and contractors once they are inside the community.


          For context, we are a global printer manufacturer and software/solutions company.  We have about 13,000 employees worldwide and probably another couple thousand contractors.

          • Re: Bet practice sharing: contractor access to internal employee communities?

            We have a federal implementation that is not integrated with the agency network for just this reason.  We basically have nothing available to the Guest User - so registration is required and we require non-staff to be invited by the community lead within a Group or related to a Space.  Non-Staff could be contractors, but could just as easily be partners from other agencies or outside subject matter experts from universities or think tanks.  We then limit their visibility to the Places they have been invited to participate and training and support spaces.


            We restrict access to horizontal communities (Spaces) via the User Group (which I wish Jive would call Roles, like everyone else) permissions so they cannot see even the "Open" Spaces unless they are specifically invited to participate.  Most content creation is done within Private or Secret Groups so others can't see that content anyway.


            We implemented an external community - but it really that in name only.  Had we implemented an internal community, we would enable the External Group Member function to allow those from outside our domain to join individual Social Groups.


            DM me and I can answer your specific questions in more detail.



            • Re: Bet practice sharing: contractor access to internal employee communities?

              Hi Patrick,


              My answer is fairly similar to Dennis and Lexmark, with only some subtle differences.


              As Dennis mentioned, with respect to our Jive system, employees and contractors are treated the same and it is up to each individual community owner to determine whether their content is appropriate for open sharing (all employees and contractors) or should be private to only their targeted audience. This level of access also gives them access to our SharePoint environment and FAST search tool to any open "all employee" content that exists within Jive or SharePoint. But we also have fairly consistent communications and "campaigns" called "Protect Lilly" that educate data / document / site / community owners to think carefully about the sensitivity of their information before determining who has access to it. But in doing so we still try to encourage open knowledge sharing as well as long as the information isn't TOO sensitive. It just depends on the work area and what they are working on.


              In addition to provisioning userid's to contractors, we also provision VPN access and userid's to Lilly systems to some external business partners for collaboration. And when a person "onboards" someone of this type, they determine the access level of that person (VPN?, Secure email?, SharePoint/Search/Jive access?, IM access?, Access to specific business apps? etc.)  Based on the elections of the Lilly contact for that business partner account, we either give them access or not.


              For example, an external software vendor that I work with that I want to collaborate with in our Jive environment. I give them a userID and elect for SP/Search/Jive access. This gives them an account, but also means they have access to any OPEN content existing in the Jive environment (or any private areas that I grant them access to). That is up to me as the contact to determine if that is appropriate. But I get a ton of "Are you sure?" warnings as I make those elections .  We figure we'd rather do that than have Lilly employees collaborating in non-Lilly systems provided by those partners putting our business data in a place we don't control...because people still need to collaboration with our external partners in one way or another...and just providing email options doesn't cut it anymore.


              For extremely secure external collaboration where we don't want those partners to have access to any of our open content, we have options with SharePoint and Box.com where we can setup some Lilly employees and some external partners to work together in a "walled garden" that only gives that external partner access to that project's specific data. So for each type of collaboration...there are options based on need and security.


              Eli Lilly, global. Headquartered in Indianapolis. 38,500 full time employees globally. Nearing 55,000 provisioned Lilly userid accounts when you consider contractor/external collaborator accounts.



              • Re: Bet practice sharing: contractor access to internal employee communities?

                I am in the financial servicesindustry with about 13,000 employees and 2,000 contractors at any given time. Like Dennis and Bryce anyone who is given a company User ID and password has access to our Jive instance along with our regular intranet. We cover any potential loss with NDAs and we also know most of our sensitive work is happening in private groups. The only restriction we have for contractors is that they can only be a group owner if it is related to their work assignment. At some point we'd like to provide limited access to external third parties, but we have other priorities at the moment.

                • Re: Bet practice sharing: contractor access to internal employee communities?

                  Thank you all for your replies - very helpful!


                  Regards, Patrick

                  • Re: Bet practice sharing: contractor access to internal employee communities?

                    This has been a headache for us for years. Our culture in our internal Jive community is one of openness and transparency. So, we encourage people to make content accessible to all unless there is a good business reason to restrict access. This has been a keystone of our effort to break down silos between different parts of the business.


                    But then what do you do about non-employees who we want to collaborate with, too? Ideally, we would just give them access to content that they need for their assignment, and NOT the entire open community. This can't be done very well with Jive, however. If the content is in a space, then we can pretty well restrict them to that and it's okay. But if it is in a group -- and of course the distinction between spaces and groups is NOT clear to many members of our community -- then we can't give them access to just that group. We are forced, by Jive's permissioning scheme, to give them access to ALL Open and Members Only groups if we want to give them access to just one group.


                    Our solution has been to introduce lots of red tape, basically, and that sucks because it flies in the face of what we are trying to do, which is to make it simple and desirable to use Jive. Non-employees have to sign a special NDA to get access to our community (and it can't be the same NDA that a consulting organization has already signed with us). If they get access to the entire community, then that must be approved by the head of HR for the division requesting this access. Then reminders must be set up around the time their access is expected to end. It's a whole checklist of things that need to be filled out and submitted. Not a nightmare, by any means, but a significant hurdle that makes using the community with non-employees difficult.


                    We're in the media business, primarily events.

                    • Re: Best practice sharing: contractor access to internal employee communities?
                      Libby Taylor

                      Patrick Fleig Do you feel like you are getting the responses you'd hoped for?

                      • Re: Best practice sharing: contractor access to internal employee communities?
                        Jeffrey Murnan

                        We handle this by clearly segmenting out our internal and external communities.


                        • For internal: we allow long-term contractors inside the walls and tell group managers to protect content that is not meant for everyone to see
                        • For external: we create private areas for partnerships.  Example: we have an area where a specific marketing agency can pass files back and forth, execute on a specific project, etc -- but we don't allow them into the entire community


                        One solution I have see others use is having a clear identity management process where the FT that brought the contractor in is responsible for his or her access.  This puts the accountability on the sponsor.


                        We work in an FDA regulated environment, so security and access controls are paramount in a lot of what we do.

                        • Re: Best practice sharing: contractor access to internal employee communities?

                          Hello Patrick,

                          We allow contractors access to our Jive instance. We are a financial company of approximately 55-60k. Everyone must agree to terms and conditions before they use the platform. Also with regard to intellectual property,measures are in place during the HR onboarding process that covers this (we all sign off on who owns what).

                          • Re: Best practice sharing: contractor access to internal employee communities?

                            Our employees and contractors use the same identity system so even if we wanted to block contractors there really isn't a mechanism to do that, assuming they have VPN access to our Jive instance. In any case, the open / social way of sharing is in line with sharing with contractors who worked with our employees. Contractors have to sign NDAs when they are onboarded so while there are some scenarios where access is restricted based on a security group for a particular space, otherwise they have access to the "top level" of our Jive instance.

                            • Re: Best practice sharing: contractor access to internal employee communities?
                              Ben Zweig

                              At Social Edge Consulting we create a user group for our team with the necessary permissions and have recently begun to add custom status icons to Social Edge employees so that our logo displays in place of the community's usual status gauge.


                              Screen Shot 2013-08-26 at 12.56.43 PM.png

                              • Re: Best practice sharing: contractor access to internal employee communities?

                                At PwC we treat contractors the same way that Dennis already mentioned. Once they get a Global User ID, which they need for email, they can access our Jive instance. We debated this for a while at the beginning of our implementation and came to the conclusion that we needed them to have full access so that they can collaborate and contribute like employees, which is essentially what we're paying them to do. We don't use Spaces so it's up to each group owner to determine who can/cannot have access.


                                For context, PwC has 182,000 employees globally and we're in the assurance, advisory and tax business (accounting and management consulting to make it simpler). I have no idea how many contractors we have on top of that global number but I'm sure it's a lot.

                                • Re: Best practice sharing: contractor access to internal employee communities?

                                  Thank you everyone for the dialogue and insights! This is what I love about Jive customers. Everyone is willing to share and help others learn!