In our last webinar, How To Account For Security With Customer Projects, I spoke about maintenance and sustainment contracts – specifically how to use them to better account for client website security.
In this post I will touch on some of the key areas in a project’s lifecycle that can be leveraged to build stronger client relationships, while also providing an opportunity to expand your revenue potential through the introduction of services like security.
Expectation Management
Have you ever been involved in a project where, from the onset, some of the stakeholders want to be the next Facebook? Then you come to find out the actual decision maker really wanted something more like Twitter? Yeah, me too!
Alignment is important from beginning to end. It’s hard to always stay aligned with your clients, but seriously important to the success of a project.
To account for this, expectation management needs to be something you start from the very first discussion. You need to continue setting expectations through the end of your engagement with your clients. I think there are a few very basic questions you need to ask yourself when first scoping a client project:
- What does success mean to you as the agency with the project?
- What does success mean for your client?
As an agency, you realize that success surpasses the end of the project. It’s not just about scoping the project, developing the solution, and watching it go live. Some could argue this is just the beginning and the real work begins after the deployment.
It’s important to introduce the importance of life beyond the launch early in the process. How often have we worked with a client who is unable to see the forest through the trees? They have the deployment date, as if it was some magical date where everything stops, only to find out that when things are live the real work begins.
Think about hosting changes and issues, new features, updates to existing features (things never work the way everyone first thought), and of course, security.
Too often, when working with organizations we find that security never made it into the conversation at all. In the 11th hour it becomes a requirement that now you, the agency, is being held accountable for. Worst yet is when the conversation is introduced after a compromise, months after a deployment. To account for this, I recommend using a process similar to how you design elements and feature requirements; security needs to be another thing that you introduce early and often.
The most important questions you want to be mindful of:
- How will security be handled?
- How will backups be managed?
- Who will be responsible in the event of an incident?
- What is their general position in regards to security?
- Will they have to work with an internal security team? What does that interface look like?
Granted, these are not all questions that have to be introduced on the first call. It is a conversation that needs to happen, early and often.
The Security Paradox with Agencies
Security to me has overlap with maintenance and sustainment, for obvious reasons like updates, site performance, and site availability. I also think security is a very important stand alone thing that needs to be included at every phase of a project, not just in maintenance and sustainment engagements.
So the next question is: When do you introduce the concept and how can you help your client manage their website security with them for the life of the site?
I encourage agencies to make security a requirement and the implementation of a security plan part of their project architecture. During the build, formalize your requirements and the client requirements. Educate them on the importance of where the site is developed and where it will be in production. Here are some other considerations:
- What are the security controls in place to protect the entire stack?
- Who has access to what and when during the project?
- Who is responsible for each area of security during and after the build?
- Make hosting recommendations
- What are some of the things you should be considering?
It’s never too early to talk about security in the relationship. From initial engagement through hand off to their production environment, you have the opportunity to socialize security and how you can help sustain their site. What I have found that works well is talking through the entire lifecycle during the initial discussions with a potential client.
For example, you have an initial discovery call to talk at a high level about what they want. This is a great opportunity to introduce how you work. Explain the estimate process all the way through deployment from QA to long term maintenance. Introduce your stance on security and its importance. You’re setting expectations from the beginning and recommending the long term as responsible partners. This gets your client thinking about all these moving parts and makes your job of adding maintenance/sustainment to the contract a bit easier to talk about.
Now that you’ve recommended from the jump, include language around security in your proposals / contracts. I liked adding a whole section talking about our recommendations and why they’re so important, specifically highlighting areas of responsibility once the site goes live. I also liked noting that security is important not just during the build, but also something that’s part of a sustainment program.
Another thing I would do is include security solution pricing as a service for the site once it is launched in the estimates. I would break it down into the key areas like monitoring, protection, availability, backups and incident response.
If you need help thinking through this process engage our team and inquire about our new plans built for agencies. These plans allow you to partner with us and extend our services to your audience directly. There are referral programs, and direct integration opportunities that will help you account for some of the recommendations above. You can also read case studies from agency owners who recommend Sucuri for client website security, including WebMechanix, Nicely Built, and Savvii.
