Organizations are recognizing the importance of data protection, but it can be challenging to ensure stakeholders understand its worth. Data Protection leaders can deploy Professional Engineers to bolster software quality, reduce risks, and provide stakeholders with assurance, helping them reap the benefits while showing their own worth.
Executive Insights:
- Data protection leaders often struggle to communicate the value of their practices to organizational stakeholders, due to an attitude of Trust and Safety not being core functional value requirements.
- Organizations must connect Safety to their bottom line and Trust to the top line to successfully communicate the value of Safety investments.
- Where there is potential for harm, Safety mandates typically arise from regulations, Duty requirements, Professional liability, Insurance baselining, and/or Safety as a value driver.
- Employing professional engineers can improve software quality, reduce security risk, provide legal certainty, increase stakeholder confidence, and promote a healthy market ecosystem.
- Data protection leaders can leverage their focus on Professional Engineers to assure stakeholder safety, thus deepening their value relationships for the long term.
A Task for Data Protection Leaders
One of the reasons Data Protection leaders often struggle to communicate the value of their practices to organizational stakeholders is the seemingly baked-in attitude towards Trust and Safety as not being core functional value requirements. Business leaders tend to be focused on a sprawling array of unending obligations striving for the perfect product/market fit, aiming for breakneck time to market, ensuring on-strategy messaging, aligning metrics to outcomes, conducting teams of humans to move in harmony, managing resources in contention, executing and measuring the impact of various layers of strategy – everything, it seems, including the untested assumption that the operational foundations of the business underneath their feet are safe.
This position can leave little room for Data Protection Leaders to have those foundational conversations on the business purpose of a trust and safety practice: are we running an inherently safe business? Are we leaving money on the table by operating less safely than we could? How would stakeholder relationships be impacted if we led with Trust? With cyber-security threats more pervasive than ever before, it's integral that organizations prioritize trust and safety as a cornerstone requirement that goes to market with the rest of the business.
Investments in trust and safety are sometimes viewed by the unaligned business as a grudging cost of operating in a connected world; when leadership holds this view, the task of communicating the value of safety becomes virtually impossible. However, by connecting safety to the bottom line and trust to the top line, Data Protection leaders can position safety investments using market logic rather than re-fighting the service cost containment battle. This positioning also helps challenge the perception that prioritizing trust and safety above the minimum required level brings unacceptable friction and cost to the value-driving parts of the business. This becomes especially salient in businesses where trust is material to customer and revenue journeys, where deals cannot close without foundational Trust Stories.
5 Different Sources of Software Defects
Historically, where there has been a reasonable expectation that software defects could lead to harm to life, health, property, economic interests, the public welfare, or the environment, safety mandates have arisen from different sources:
- Safety as a Value Driver: go-to-market with a Trust Product that communicates process and organizational safety to Trust Stakeholders, and leverages evidence of safe practices to power Trust Stories to differentiate and underscore the reason to buy, or
- Duty Requirement: A Compliance or Duty requirement forces investment in security sufficient to overcome the present friction, or
- Practitioner Liability: professional standards mandate the delivery of safe work product, reducing unsafe motions upon pain of professional sanction (think doctors, lawyers, fiduciaries, engineering, and other regulated professions), or
- Insurance Baselining: actuaries designing insurance risk models will redline certain anti-safety and insecure behaviors, practices, and conditions as prima facia uninsurable, which drive baseline safety investments (as initially occurred in the construction and medical industries when insurers stepped in where state regulators failed to protect stakeholder interests), or
- State Regulation: state regulators, acting on past evidence of harm, will implement safety, security, and trust standards in defense of the public welfare, as occurred in aviation, transportation, banking, construction, insurance, CPG, and other safety-first industries.
The "Practitioner Liability" driver is the most interesting angle as it gets to the heart of whether software engineers have a duty of safety in the same way that other engineering disciplines do. This is a complex topic that is sometimes overshadowed by a values clash between engineering culture and business stakeholder requirements. There has always been tension between engineers who want to "build it right" and businesses that want to go to market now, and this is best seen in the software industry where code safety stands at the centre of a constant tug-of-war. While a civil engineer may be protected if they refuse to sign off on an unsafe bridge design, no such protection exists for software developers made to sign off on unsafe software who are not protected by a professional engineering designation. A Data Protection leader tasked with communicating a commitment to trust and safety can present this investment as aligned to the interests of all value stakeholders.
Professional engineers are held to a higher professional standard and are licensed to practice in their jurisdictions, with professional requirements pertaining to ethical practice, duty of care, regulatory compliance, and other safety-related areas front and centre in the licensure process. Organizations such as the IEEE Computer Society and the International Council on Systems Engineering (INCOSE) have lobbied for the adoption of professional certification standards for software engineers to ensure the knowledge and skills necessary to develop secure and reliable software products; however, market pressures have prevented real momentum from building behind such initiatives.
Even so, employing professional software engineers can improve software quality, reduces security risk, provides legal certainty, increases stakeholder confidence, and promotes a healthy market ecosystem in which all stakeholders can thrive. Data protection leaders can promote their reliance on professional engineers in key posts to assure stakeholder safety and underscore relatable investments that strengthen value relationships for the long term. Ultimately, who you hire is who you are, and presenting safety as a structural conversation with a full view of all stakeholder interests can be the ultimate differentiator where it matters: in the heart of Customer.
