Security Consultant: How do you define your scope?

Q: Security Consultant: How do you define your scope?
As I make my foray into the security consulting world of side work, I am wondering how other security consultants out there have defined their scope as to what services they offer and where they know to draw the line and/or keep a client within the bounds of what the scope actually is. I know it has a lot to do with your areas of expertise, but what helps you (anyone who might wish to answer) make this definition?

A: Hi ....,
This is a good question. And there is no silver bullet.

I have been managing hundreds of information security SOWs (statement of work documents) every month for the last 5 years..This is a lot about security; it is more about the delivery. Here are a few things that we learned by tough experience (in no particular order):

1- Do not make it one security consultant's job to define scope and the deliverables of the SOW. Build a workflow with multiple check points for peer review. If one consultant defines the scope, make sure that others review it. Peer review is the harshest part for every security project. I think that it is easier to criticize than doing the actual job so you ca get a good reality check prior to sharing your draft scope with client. Engineers/Consultants have a tendency to omit their own mistakes. Shortcuts are always favored by engineers (by nature). Use different teams, e.g. security consultants define the scope, delivery team verifies it...

2- Always share draft versions of the scope with the client. Verbally communicate deliverables. Give client a chance to review to the draft SOW and allow changes. Use change control on the SOW documents.(make sure all revisions are recorded)

3- Create an internal risk document; where you internally discuss possible risks about the project in advance. Make sure that risks are addressed prior to final approval

4- Keep all parties involved. Make sure that your process is transparent to all key stakeholders including project management, client, account management, finance, legal, consultants, engineering, support, vendors etc.

5- You may try using pre-defined scopes with predefined deliverables. Even if this is the ideal, it rarely works, every client is unique. You may better have standard methodology documents and customized deliverables based on top level methodology document. I may elaborate more on the à la carte scoping with prebuilt blocks for security, based on the security project type (e.g. policy /compliance consulting is different than hardware/software deployment or deployment is different than assessments etc)

6- Put everything is writing. No verbal communication will help when there is a dispute. All deliverables should be clearly defined. I like the following clause from our SOWs: "The scope of this project excludes all services and related issues that are not mentioned in this SOW and any additions or changes will be done as set forth in the change control procedures contained herein. Any services not part of this SOW are considered Out of Scope and additional charges may apply"

7- Make the security consultants are responsible for the delivery. They should understand what is easy what is not on the field. They should be able to perform actual deliverables on time, and they should be liable when their scope does not match the reality. Continuous audit of deliverables and the improvement is a must. Make sure that you have post mortems on failures and all of the failures are addressed.

8- Share your internal workflow with the client; make sure that the client understands how you work. Share service descriptions, SLAs, professional service agreements in advance. Make sure that your security consultants relay this information properly. Clients will understand whatever they would like to hear, so you need to cover all bases for confidentiality, deliverables, lead times, cutover times, success criteria, privacy, change management, costs, points of contact, project management, test plans etc.. If they are not written, client's expectations may certainly be different than your consultants’...

Well I think we have a limit on the answers page, but let me know if you have a specific question.

regards,
- yinal ozkan