Skip to content
Aaron ReaApr 1, 2021 12:00:00 AM5 min read

Tips for a Successful Cloud Security Consulting Engagement

Tips for a Successful Cloud Security Consulting Engagement

Tips for a Successful Cloud Security Consulting Engagement

Tips for a Successful Cloud Security Consulting Engagement

As a cloud security consultant I have seen engagements and customers of all shapes and sizes. From the newly funded startup looking for guidance going into their first audit, to the “you’ve definitely heard of us” corporations laying the secure foundation for thousands of developers and technologists, we’ve seen some stuff. With this breadth of experience, patterns common to all successful engagements have emerged. This article will enumerate some often overlooked but critical pillars of such engagements.


In my experience, one of the most overlooked and undervalued stages of an engagement is the very first: on-boarding your consultants. While the most varied due to scope, policy, and a host of other factors, an efficient and complete on-boarding is a great bellwether of the overall success of an engagement. Key factors include the requirement for and procurement of:


  • laptops
  • 2factor hard tokens


  • vpn/remote access licenses
  • workflow/project management tools (Jira, ServiceNow, etc)
  • data warehouses
  • version control systems (Github, Gitlab, etc)

Identity and access credentials:

  • physical badges
  • corporate domain access
  • cloud environment access

Communications tooling/access:

  • internal email accounts
  • real-time messaging (Slack, Teams, etc)

Mandated training:

  • industry compliance
  • corporate compliance
  • technology compliance

The delay of any of these factors, and this is certainly not an exhaustive list, sets an engagement behind immediately. In the lead up to kick-off, all stakeholders should be aware of possible impediments to the on-boarding process and be ready to escalate accordingly.

Furthermore, time to complete these tasks should be factored into project timelines and scope. If 8 hours of corporate compliance or technical training is required, a one week project timeline may be insufficient. In the best cases, an individual from the customer side is designated to take point on removing these blockers. While rarely glamorous or simple, this role is key and the person should be both empowered by and knowledgeable of the greater scope of the project.

Workflow Establishment

I am not a project manager, and have never played one on TV, but the value of a solid plan and execution is undeniable. The most successful engagements I have been involved in established a workflow from the start and pivoted quickly when parameters changed. This doesn’t necessarily mean we spent all day updating tickets and in retrospectives, though. A small project may not warrant the time to track every work item and deliverable in such detail. Furthermore, large or long projects did not always benefit from the textbook management structures either. There is a natural flow, generally derived from the cultures of both consultant and the client. Every successful project, however, established a timeline and hierarchy of deliverables and held both sides accountable for delays and blockers.

Another note on this stage of a project: discovery. There will be an initial set of inputs/access that is needed to accomplish the original task. This will evolve throughout the duration but a baseline will be required to get started.

  • Is a weekly database or log dump needed to compile a report?
  • Are there existing services that can augment or shim the work being done in the short term?
  • How can these be made available to the team quickly and efficiently?
  • Is any further training or authorization needed before granting access?

Questions like these come up in every engagement.


An engagement has been established, access has been granted, data and engineers have been wrangled. Now the real work begins and often two perspectives emerge which I will refer to as short and long tail adjustments. As commits turn into days, days into sprints, and sprints into months, patterns of change will emerge. Engagements succeed in a balance of the needs of the day/week with the goals of the month/quarter/year. How will spending a few hours today investigating a new library or API call affect a dataset due to be reported on next month? Does newly proposed legislation potentially negate/increase the need for this work? These are a few of the factors that can affect the goals and outcome of an engagement once it has started.

Short Tail Adjustments

On the shorter time scale, tactics are always ripe for change. A language/pattern/tool/API may be working well enough in “proof-of-concept” or “MVP” code but take a moment to consider how likely it is to scale efficiently. Likewise, an output or report based on a particular data set may have value but there may be a trade off between that value and cost of recurring production. Automation can help, but only if the juice is worth the squeeze. Which brings us to another heuristic: (acceptance) test early and often. Streamlining the feedback loop between producers and stakeholders is critical to a successful engagement. Not only has this helped to identify and remediate gaps quickly, often it will lead to the discovery of related or tangential efforts that can be inherited from or collaborated on.

Long Tail Adjustments

On the longer time scale, things tend to change. New initiatives are born. New regulation is enacted. Customer needs and wants evolve. Especially in longer engagements, plan for the plan to change. In some cases these changes may deprecate work but often there is opportunity to refactor or reuse. As an engagement comes to a close, one should not have to squint too hard at the outcome to see the original goals and motivation.

A Smooth Landing

Finally code has been deployed, systems audited and data reported on. As an engagement approaches the finish line, documentation and a clean handover of new automation become critical tasks. Internal owners should be identified and brought up to speed if not already directly involved. Documentation should be reviewed for clarity and completeness. In the most successful cases, an eye for retrospection emerges and the opportunity to evolve is presented. A retrospective can provide valuable insight for both consultants and clients and should be considered where time and budget allow.

While every cloud security consulting engagement is a little different, these factors have proven vital to success, time and again. Whether you are looking for one last review of your architecture before launch or planning and migrating to an enterprise wide security pipeline, ScaleSec can help.


The information presented in this article is accurate as of 7/19/23. Follow the ScaleSec blog for new articles and updates.