6 IT rules worth breaking — and how to get away with it

IT is a discipline of policies, protocols, and firm guidelines. But sometimes breaking bad is the only logical thing to do. Here’s how to do so while mitigating risks.

There comes a time in every IT leader’s life when a key decision must be made: whether to follow an established rule or, as a matter of necessity, break precedent and embark on an alternate course.

Management rules typically exist to enable faultless decision-making, set a foundation for consistent operation, and provide protection from risk, observes Ola Chowning, a partner at global technology research and advisory firm ISG. “Breaking a rule often happens after the CIO weighs the risk of removing or retaining a mandate,” she notes. “Both options represent some level of financial, regulatory, or performance risk.”

Rules can be broad or precise, Chowning says. They can apply to people, processes, enterprise behavior, and technology requirements and risks. All are established to help the organization meet compliance and achieve essential goals.

SUBSCRIBE TO OUR NEWSLETTER

From our editors straight to your inbox

Get started by entering your email address below.

Please enter a valid email address

Still, there are some occasions when following a long-established rule simply doesn’t make sense. Here’s a rundown of six IT policies or protocols that, in certain situations, with certain guardrails in place, can be disregarded in order to perform what needs to get done.

1. Code change management processes

One rule that can occasionally be broken without outside repercussions is sending new code or a new capability into production without first following a required change management process, Chowning says.

Change management aims to ensure a consistent level of oversight, confirming that prescribed levels of testing have been completed, that operations is ready to accept the change, and that there are sufficient fallback plans in place in case the change results in customer or business disruption. Yet on the occasion when a specific change needs to be quickly deployed, it can be okay to skip the change management process or revisit it later.

The biggest risk facing an IT leader who circumvents the change management process is the possibility of a significant negative impact on business and/or internal operations. “An important aspect of this sort of rule-breaking is to mitigate the risk as quickly as possible by following through, post-change, with the activities that would have addressed these items if the initial change management rule had been followed,” Chowning says.

Weighing the relevant factors clearly and concisely is necessary to justify the decision to skip the change management process. Leaders who can establish financial- or time-related benefits to mitigate the risk of breaking the rule can show they have thought through the decision’s repercussions and have an objective view of the balance between risk and value, Chowning says.

2. Change freeze period rules

An IT rule that can sometimes be discarded is the change freeze period rule, during which no new system implementations or updates are allowed for a specified amount of time, typically around key business cycles or holidays.

There are situations when this rule might need to be broken, such as when a critical security patch or an urgent business need demands immediate system changes, says product strategy consultant Michael Hyzy. “In such scenarios, the immediate benefit of implementing the change outweighs the structured caution that the rule intends to enforce.”

Potential risks to consider include system downtime, workflow disruptions, or even security vulnerabilities if the cancellation isn’t managed intelligently. “Therefore, it’s vital to conduct a rigorous impact analysis and have rollback plans in place before proceeding,” Hyzy advises.

Justifying the decision requires open communication with IT team members and management leaders. “It starts by laying out the situation, the risks of not making the change, and the preparedness measures in place to mitigate potential fallout,” Hyzy says. “The goal is to get everyone on the same page and make an informed, collective decision.”

While rules are essential for maintaining order and predictability, exceptional situations call for exceptional actions, Hyzy says. “Being too rigid can sometimes put the organization at more risk than a calculated rule-bending, provided it’s done transparently, intelligently, and with full preparation for any contingencies.”

3. Automation prioritization commitments

Automation, particularly when incorporating artificial intelligence, presents many benefits, including enhanced productivity, efficiency, and cost savings. It should be, and usually is, a top IT priority. That is, unless an organization is dealing with a complex or novel task that requires a nuanced human touch, says Hamza Farooq, a startup founder and an adjunct professor at UCLA and Stanford.

Breaking a blanket commitment to automation prioritization can be justified when tasks involve creative problem-solving, ethical considerations, or situations in which AI’s understanding of a particular activity or process may be limited. “For instance, handling delicate customer complaints that demand empathy and emotional intelligence might be better suited for human interaction,” Farooq says.

While sidelining automation may, in some situations, lead to more ethical outcomes and improved customer satisfaction, there’s also a risk of hampering a key organization process. “Overreliance on manual intervention could impact scalability and efficiency in routine tasks,” Farooq warns, noting that it’s important to establish clear guidelines for identifying cases in which an automation process should be bypassed. “This decision should be communicated transparently to both customers and internal teams,” Farooq recommends.

4. External network connection prohibitions

When it comes to critical infrastructure, one commonly held IT rule is never linking production systems directly to external networks. Yet Kristin Demoranville, CEO of AnzenSage, a cybersecurity consultancy focusing primarily on the food industry, disagrees. “While this rule is established with the best intentions to protect sensitive systems from external threats, there are instances where it might be necessary to make exceptions,” she says.

There are times when real-time data sharing becomes imperative, Demoranville states. “For instance, if there’s a need for immediate quality control checks with external labs, or when collaborating with suppliers on a global scale for traceability purposes.” In such cases, direct connectivity can expedite processes, ensuring food products meet safety and quality standards without delay.

While IT rules and protocols are essential, they should serve the mission, not hinder it, Demoranville says. “As we navigate these decisions, we must always prioritize safety, quality, and transparency.”

5. Asset management regulation

Breaking this rule can make sense whenever a technical issue arises in the inventory data being captured, or in situations where end-users are being blocked from accessing enterprise systems, says David Scovetta, security and compliance director at custom forms developer FormAssembly. Asset management regulation may also need to be tossed temporarily aside whenever a new system that doesn’t conform to existing inventory criteria is deployed.

Before breaking this rule, make sure you’re considering the risks, Scovetta cautions. “Addressing these scenarios usually requires cooperation between IT and security leaders, yet it can make sense to break the rule as long as safeguards are in place that can characterize devices by configuration policies, even if you don’t have a firm accounting for the device or its owner.”

6. Any IT rule or policy — in an emergency

Established rules can sometimes be bent or ignored when a crisis situation suddenly emerges. “There are a few scenarios where asking for forgiveness instead of permission makes sense,” says Jesse Stockall, chief architect at Snow Software.

Security incidents, for instance, often require decisions to be made quickly, and if high-level decision-makers are unavailable, determining a response can be critical. Stockall notes, however, that important decisions should still be based on seniority and trust. “Junior employees should not be going rogue,” he warns.

Still, IT is an inherently innovative space, which means that doing things by the book won’t always yield the desired results. Someone with experience and good judgment can probably bend rules as needed, and often these types of employees are given a longer leash.

Still, policies exist for a reason, Stockall says. Rule-breaking should never become a routine IT practice. “Rogue employees invite risk, spoiling workplace flexibility for everyone with egregious behavior,” he explains. “Suggesting there’s an IT policy you can always override is bad practice.”

Stockall believes that IT is moving into an era in which there will be even more rules and policies. “These guardrails will exist for a reason, including an increase in cybersecurity attacks, risks to intellectual property, and the unknowns surrounding generative AI.”