5 Minute Read
This post is written for the benefit of two audiences: independent contractors and companies large enough to have their own internal or outsourced IT departments. If you are reading this from the perspective of one of these audiences, I encourage you to think about this topic from the other audience’s perspective.
Employees face barriers when they dutifully follow their employer’s handbooks. The purpose of these documents is to dictate acceptable behaviors and restrict the use of company property and technologies to work-related activities. These documents reflect intentional decisions by management to conduct business legally in their industry, establish company culture, and provide a collaborative environment for their employees. Companies vet the technologies and services they choose to run their business, and select the tools that provide the Goldilocks combination of features, fitness, and affordability. By following their employer's guidance, employees are practically guaranteed to use the same tools as their colleagues at the company. This curated portfolio of technologies and services unlocks tremendous productivity possibilities. By enshrining the list of approved technologies in the company handbook, an expectation of engaging in collaborative behavior for employees is established, and harmony is promoted among workers.
However, there is a wrinkle in this scheme. Organizations frequently work with third parties who are not employees. Have you encountered challenges due to this arrangement in your own professional experience?
I should acknowledge something about this topic before diving deeper — it won't be edge-of-your-seat engaging. When these issues are encountered professionally, we tend to step around them or try to solve them once and move on, ignoring any SNAFUs. In practice, even though it's not the right thing to do, employees and vendors share account passwords, and rarely do things go wrong. That said, would it not be better if practices involving contractors evolved to match their fluidity?
Sticky Situations
Years ago, a company I worked with had a VPN server running on their firewall. Authentication to the VPN was controlled using Active Directory accounts, and based on domain policies, these accounts had a password that expired every 90 days. Standard cybersecurity stuff. The employees at that company would receive password expiry notifications several days before passwords expired, but vendors who used the VPN to support their solutions would almost never sign into a domain-joined PC. This means they would never see the password expiry notifications. If their support were required in an emergency, there’s a decent chance their account would be locked due to an expired password.
What is the best way to resolve this issue?
In another scenario, I worked with a client that had strict Bring-Your-Own-Device (BYOD) policies. We’re talking killswitch capabilities for hardware that enrolled in their BYOD program. This client used email as a communication channel, and the account I used to access their systems had an associated email address published in their company address book. If I used this communication channel, and set the email account up on my phone, the client would have had a wiping capability for my entire phone. One honest administrative mistake, or even a disgruntled client, could have done serious harm to my business if a wipe was triggered! But what if someone who worked for that client sent an urgent message to that email address? If that message was missed, it may be perceived as a customer service knock against me.
Contractors’ Challenges
Contractors, by law, are not to be treated as employees and thus have fewer guardrails than their counterparts. Contractors can select technologies from practically any vendor they wish to try or use to run their own business. However, their client-facing work will inevitably involve sharing technologies with their clients. Contractors are compelled to align with their client’s interests and collaborate on projects, but they must also consider the complexities of working efficiently with multiple clients. Unlike employees, who are expected to exclusively work for their employer and (hopefully) no other business on their company-issued and managed devices, contractors need to consider how they will appropriately run their own businesses + serve their clients in a practical, secure fashion.
Clients have two main considerations when it comes to working with contractors:
- What are the smartest approaches to collaborating with contractors when a project requires sharing systems? What if these systems are self-hosted or vendor-managed?
- When the contractors are working with technology or software teams, these considerations are top of mind for the IT domain. These considerations can also arise from a Business Operations domain when work involves contractors from HVAC, industrial automation, or physical security systems.
- What are the agreement mechanisms, similar to labor laws or employee codes of conduct, appropriate for establishing expectations and enforcing the approaches determined in consideration 1? These considerations may be influenced by the Human Resources domain.
Employee Handbooks vs. Services Agreements
Working as an employee is relatively straightforward. Federal and state labor laws address many basic policies employers must follow to promote a functioning and safe society. The employer-employee relationship comes with other perks, like FICA matching, and benefits, like retirement savings plans and health insurance. Even employees who dislike their companies or jobs have less to worry about than contractors who do similar work. As long as employees’ behavior remains within the guardrails of their employer’s handbook, they are free to carry out their work.
Independent contractors providing consulting services do not receive many of the same benefits employees do. These benefits include intangibles like the guardrails bestowed by employee handbooks and government regulations.
Consider the many ways independent consultants make their living. They can be called upon to work from a home office, a client office, or from the road at essentially any time. Requiring 40 hours a week at a single client's office - using only client-issued hardware - is incompatible with how many independent consultants operate their business. Companies minimize their risk by issuing tightly managed systems to their employees. Some excellent technologies, like Unified Threat Management and Data Loss Protection systems, are entirely appropriate to run on company-issued devices. These would enable overstepping “reasonable” levels of monitoring and control if used on an independent contractor’s laptop.
Unless a client already has comprehensive systems, onboarding procedures, and policies to work with independent contractors (a rarity in my experience), these contractors need to pay special attention to the language used in the contractual agreements. Written agreements are appropriate documents to call out things like:
- Will the contractor be expected to use their own PC or Laptop?
- Consider the scenario of working with multiple clients or working while traveling. Is having a client-issued device for every client realistic or desirable?
- How will cloud systems be accessed (project management applications, productivity platforms, or other collaboration tools)?
- Will the contractor use their email account to sign up with the cloud service provider?
- Will the contractor or client pay for any applicable licensing costs?
- Does the cloud provider support accessing multiple organizations’ environments from a single account?
- If the contractor has to use a client-managed email account to access the service, what additional conditional access policies could create issues accessing the system?
- If the platform supports email notifications, how will alerts and alert responses be routed appropriately?
- How will client-hosted systems be accessed?
- Will the client provide remote access solutions involving VPN clients and technologies like Microsoft Terminal Services? This tried-and-true approach can help facilitate secure, walled-off access to client systems.
- Does the agreement specify that the client needs to provide access to their places of business and other restricted areas if applicable?
Choosing Systems as a Consultant
Independent consultants are, in some ways, better off than their employee counterparts because they have a wide world of collaboration, email, cloud storage, self-hosted services, and other SaaS applications available to them.
This is an opportunity I have embraced as I was able to try (and sometimes purchase) solutions to help run my own business. Often, I merely wanted to learn more about them. White papers, support documentation, and YouTube videos are reasonably effective at helping clients evaluate a new or unfamiliar solution, but there is no replacement for some actual hands-on time when it comes to learning these programs. Not to mention forming vendor relationships, vetting capabilities, and planning implementations. Having familiarity with some of the A-list SaaS solutions and technologies is helpful because the clients I work with look to me as an expert who can help to inform their decisions.
To any vendors who have come across this post — there are two features I rank as higher importance than almost anything else:
- Guest access
- Multi-organization support
Part of the promise of cloud computing is secure access to the tool anywhere, by anyone. The "anywhere" problem was neatly solved by the invention of the World Wide Web. Our species has become fairly adept at reliably and quickly transmitting a 1 or 0 anywhere on our little blue orb, but equal progress has eluded solvers of the identity problem. Granting secure access "by anyone" to proprietary systems and information is not a simple physics problem like the one we've solved in networking. Proving identity, and preventing falsification, is a problem tormented by human nature. Technologies like biometrics have tried to use our unique physical characteristics as proof of identity for decades. However, their limited usage and the persistence of one and two-factor authentication methods are proof we still have a long way to go.
In the business world, we have coupled the concepts of identity with policy enforcement, only complicating matters further. Authenticating identity and policy enforcement share the goal of preventing unauthorized access to sensitive information, but the boundless requirements of enforcing different policies across different platforms have led to numerous incompatible solutions for proving identity. Technologies that facilitate “commonizing" policy enforcement at scale across platforms have emerged, but they are generally restricted to the "Enterprise" market. Want to use your AD groups for granular application security? You better be ready to pony up for an expensive subscription.
I'd like to double-click on that "Enterprise" term, as it has become a keyword that denotes a greater likelihood that features like guest access and multi-organization support are offered as part of a solution. This term is also associated with vendors' highest-cost plans, as it is targeted at the largest organizations with the deepest pockets. Tangentially, this is a huge pet peeve of mine. Security Assertion Markup Language and Single Sign On are particularly beneficial to small-to-medium-size customers as these enable efficient administration for the understaffed IT departments common with this size of organization. Enterprise-size customers are likelier to have siloed solutions and shadow IT operating with technically limited capabilities. Lacking professional IT in their siloed departments, they administer SaaS just like mom-and-pop businesses that can't access Enterprise-tier products because of unaffordability or ineligibility.
The ability to empathize with the idea that consultants make a living by serving many clients, and choosing solutions appropriately, goes a long way towards achieving the goal of “employee handbook”-like harmony.
Providing Consulting Services using Client Systems in Practice
As trusted experts, consultants are obligated to be good stewards of their clients’ systems, as they are often trusted with high levels of access to their networks and applications. Aside from working on client systems, independent consultants are often responsible for performing business administration activities for their own companies as well. These include time tracking, billing, bookkeeping, banking, paying taxes, conducting research, marketing, and working with other vendors. Independent consultants have unavoidable risks that must be dealt with using mitigation, following these five tips.
- Use web browsers, email clients, and productivity tools that support multiple profiles. This provides little security, but provides excellent value in convenience and preventing professional errors.
- Use technologies like VPN and Microsoft Terminal Services (RDP) to remotely access client systems.
- Use unique, complex passwords alongside multi-factor authentication whenever possible.
- Use virtual machines (running locally or hosted by a cloud provider) to isolate sensitive activities like using Domain Admin or Root accounts.
- Act professionally at all times.
In the near term, I predict technologies like PC-as-a-Service (a cloud-native evolution of Virtual Desktop Infrastructure technologies) will become the new table stakes for consultants working on their clients’ systems.
Whether you’re a business collaborating with consultants, or a consultant in need of guidance, finding that seamless working relationship is key. Let’s talk about it; we can provide the support you need for a smoother journey ahead.
| 9 Minute Read
6 Minute Read
| 7 Minute Read