There are standards, principles, and best practices.

And then, there are non-negotiables. When a CIO sets a non-negotiable, it’s a clear message to the staff of how it must be ingrained in culture, behaviors, decision-making, architecture, tools, and configurations.

Several months ago, I shared six important AI and data governance non-negotiables, introduced what non-negotiables are, and recommended how to define them. I suggested non-negotiable one-pagers, even though these can’t fully define governance, because non-negotiables must be simple to understand what they are and why they’re important.

Why DevSecOps needs non-negotiables

DevOps first emerged to bring collaboration and balance between development teams that want to deploy fast and operations teams that need reliability and stability. A set of disciplines and tools emerged to help bring these sometimes-competing agendas in alignment. For example, CI/CD ensures consistent deployment procedures, and IaC is used to stamp out dev, test, and production environments with common configurations. 

DevSecOps was a v2 branding aiming to bring security best practices to the forefront and to highlight the importance of continuously improving fundamental practices.

However, many companies have struggled with organizational implementation. Does DevSecOps mean one agile team with responsibilities for dev, sec, and ops? Do self-organizing agile teams mean they get to pick their own tools and ignore standards or best practices?

I am opinionated on these matters, and in a recent CIO.com article on enterprise DevOps mistakes to avoid, I wrote that empowering teams to select tools without standards is a key mistake.

Platform engineering is one way to use technology to create standards. A second comes down to simple communication, or in other words, defining the non-negotiables and evolving them over time.

I consulted with several experts to develop this list of ten important DevSecOps non-negotiables.

1.     Balance backlogs with security and IT ops priorities

The product owner role does not mean feature czar. I’ve written extensively on potential bad behaviors and the importance of ensuring balanced backlogs that address security, operations, and technical debt.

“When business owners reward agile delivery of new functionality and “developer productivity,” they inadvertently disregard longer-term consequences that make up technical debt, says Amir Rapson, co-founder & CTO at vFunction. “This leads to diminishing engineering velocity, declining developer and client satisfaction, and a breaking point in the application lifecycle where the word “modernization” becomes an unavoidable topic.”

A best practice is to set guidelines for product owners – maybe not at short-term sprint and release durations – more like quarterly and roadmap-level guidelines. If a product owner has pushed the feature gas pedal over six months without listening to the team on tech debt issues or following through on security priorities, then perhaps it’s time to set a non-negotiable around balanced backlog priorities.

2.     Define user personas and departmental workflow needs

One of the bigger issues facing devsecops teams is the drive to push features out without considering end-user adoption and change management. DevOps teams that overly generalize departmental and end-user needs need design thinking practices and a defined customer-focus non-negotiable.

“Leaders must keep in mind that every team works differently,” says Dan Root, head of global strategic alliances at Barco. “Devs may need long uninterrupted sprints, whereas agility for corporate functions may be more high-touch. It should be non-negotiable that tech choices must facilitate productivity for all workers, or else face the risks of a poor employee experience, shadow IT exposures, or elevated turnover.”

CIOs should lead by example by developing meaningful relationships with stakeholders and guiding DevSecOps teams on collaboration. While selecting too many department-specific tools and shadow IT are problematic, personalization, low-code, and configurable SaaS are all tools teams can use to optimize workflow experiences.   

“CIOs are equally responsible for employee experiences as other C-Suite disciplines, and setting a non-negotiable benchmark on empowering collaboration and agility for all teams via their stack,” says Root. “Using their platforms for telemetry to prioritize spending that informs broader organizational policies and advocate for tools that align with what users in every department need to thrive.”

3.     Follow security by design standards

I received several recommendations on security non-negotiables.

 “Security is a critical, resource-intensive priority that requires constant vigilance as threats evolve,” says Rajesh Ganesan, president of ManageEngine. “To navigate this complex landscape, CIOs must carefully balance business goals and security needs, ensuring they choose the most relevant and effective standards. Once in place, it’s essential to clearly define expectations and enforce them through streamlined processes, advanced tools, and skilled teams.”

The challenge is getting teams on the same page regarding what “security needs” actually mean. What does “security by design,” or “zero trust,” or even “security compliance” mean in your organization? While all the requirements may need a book or a wiki to be fully defined, CIOs should initially express what security by design means as a non-negotiable.

“Security must be integrated seamlessly across every phase of the IT lifecycle—from hardware procurement to design, development, and operations. A proactive approach ensures security is built in from the start, reducing vulnerabilities and delivering robust protection across the organization,” Ganesan says.

4.     Establish a select few standardized and secured paths to production

IT departments with multiple CI/CD tools and customized pipelines for different applications are fairly common problems. Allowing self-organizing teams to develop customized paths to production is highly problematic for CIOs needing consistency in security and compliance functions.

“CIOs must define non-negotiable security standards prioritizing practices like code reviews, automated testing, and regularly updated systems,” says Rocky Giglio, director of security GTM and solutions at SADA. “CIOs must build these security measures into the earliest stages of development or architecture to ensure that they address vulnerabilities, such as zero-days, before production.”

A non-negotiable could set a bar for requirements, but even better is to enforce a few common deployment pipelines that DevSecOps teams can configure and improve.

“Building security into a process takes governance and must go beyond audit checklists,” adds Giglio. “CIOs should continuously assess security measures and make iterative improvements to achieve the desired outcomes. Success lies in continuously refining and strengthening security protocols across all areas.”

5.     Collaborate on a true DevSecOps approach to tool selection

If DevSecOps teams shouldn’t have full authority on tool selection, can infosec teams force tools down on agile development teams? A non-negotiable on the required collaboration is needed when dev, ops, and security leaders are not aligned on tool selections.

“Complex and time-consuming security requirements increasingly burden application developers,” says Gopal Dommety, CEO at OpsMx. “They’re often mandated from the top down without any regard for how the security frameworks will impact the development team. This additional workload can lead to security measures being overlooked or bypassed to meet tight deadlines, introducing vulnerabilities into applications.”

I’ve written on how architecture review boards (ARBs) need a rebranding for the modern age. Beyond rebranding and a non-negotiable requirement to collaborate on tool selection, CIOs should then ask dev, infosec, and IT ops functional leaders to design an efficient process for tool selection that they all buy into.  

“Developers are the key to a successful application security program, so companies are bringing developers into the planning phases and making tool choices early on instead of pushing security tools on developers,” says Dommety. “By integrating automated security tools early in the development workflow to simplify security processes from the get-go, developers will have user-friendly solutions that minimize manual intervention, allowing them to focus on coding while ensuring security is maintained.”

6.     Review security and compliance before integrating new software components

While infosec may want the authority to select tools, it’s the dev teams who often want full control over software components, including platforms, frameworks, API services, and libraries. All I can say is, yikes! While a process is needed, CIOs should establish compliance as a non-negotiable.

 “Software bill of materials or SBOMs should be the norm, especially in compliance-driven sectors,” says Law Floyd, chief of security operations at Telos Corporation. “Understanding each component utilized in the software is paramount for security and compliance conscientious organizations.”

CIOs should address these challenges: Developers disclosing before using new components, infosec efficiently conducting their security reviews, collaborating when there’s conflict, and decision-making authorities to finalize paths forward.  

“Developers should also be transparent about what open source components are being used,” adds Floyd. “Before using them, they should thoroughly vet what they are signing up for from any terms of service, even though this requires each TOS to be reviewed by personnel external to development, such as a legal team.”

7.     Never share account access or demand root access

Yes, I still hear teams asking for root privileges for speed, convenience, or to circumvent the required collaboration.

“Visibility for accountability should be non-negotiable, and shared administration accounts, ambiguous accounts, and the like should not be allowed,” says Floyd of Telos Corporation. “This isn’t just to hold individuals accountable but is also needed to understand each element of an attack if it occurs.”

This non-negotiable may already be in place in large enterprises with compliance requirements. It can be critically important in smaller IT shops and startups because of the security risks and also recognizing that closing out root access is a non-trivial security debt to address.

8.     Include security training in learning and development priorities

I strongly advocate for lifelong learning and expect every team member to propose their yearly learning and development priorities and plans. CIOs should help DevOps engineers, developers, and SREs establish career paths, and learning programs should Include training around security standards and tool configurations. Helping ambitious DevSecOps engineers advance their careers is an advised non-negotiable for organizations that want best practices ingrained as behaviors.

“While regulatory compliance like GDPR or HIPAA might not apply to every business, adopting and enforcing recognized security benchmarks should be a standard practice,” says Christopher Hendrich, associate CTO at SADA. “For critical infrastructure components like Kubernetes, databases, and cloud storage, leveraging frameworks like CIS and NIST and enforcing them through policy engines is essential for basic governance capabilities.”

9.     Excel at continuous testing before increasing deployment frequency

Too many dev teams still want to increase deployment frequency without understanding the true business need and whether they have sufficient guardrails in place to ensure reliable releases.

My non-negotiable is whether these teams have mature continuous testing practices and review this continuous deployment checklist to determine their readiness. Other continuous deployment prerequisites to evaluate, especially for large-scale mission-critical services, include feature flagging, canary release strategies, rollback procedures, and minimal observability standards.

CIOs should define a non-negotiable that points to a list of minimal requirements, require teams to conduct a business review with stakeholders to capture deployment requirements, and conduct a readiness and risk assessment.

10. Take breaks, recognize stress, avoid burnout

One of my recent articles for CIOs was titled from burnout to breakthrough, and it highlighted some of my concerns about the stresses facing DevSecOps teams. One data point is worth repeating here:

The word “burnout” appears 42 times in the 2024 Accelerate State of DevOps report, and it has many findings about stressed-out teams and the elevated risks around burnout. “Overall, our findings show small but meaningful decreases in productivity and substantial increases in burnout when organizations have unstable priorities.”

My non-negotiable for DevSecOps team members is to take breaks, use allocated vacation time, and take advantage of hybrid work policies when possible. I recommend training managers on sensing the signs of burnout and seeking help for people who need it. Team leaders should review these different ways to disconnect and relieve stress.

What other DevSecOps non-negotiables belong on this list?