There’s a lot of talk these days about AI, cloud growth, and the future of digital infrastructure. The reality beneath all of it is something much more physical: data centers. Keeping those data centers running requires a workforce of skilled tradespeople and technicians who rarely make the headlines.
That’s why I believe we’re in the middle of a blue-collar gold rush.
As the data center industry grows, so does the demand for electricians, HVAC technicians, mechanics, facilities engineers, controls specialists, and other critical operations talent. In many of our high-growth markets, that demand is outpacing supply — and it’s changing the way we think about recruiting.
The reality is, this talent is in high demand everywhere. We’re not just competing with other data center companies. We’re competing with manufacturing, energy, semiconductor fabrication, telecom, and other industries attempting to hire from the same skilled labor pool.
The reality is, this talent is in high demand everywhere. According to a 2025 Deloitte survey, 63% of data center executives cite a shortage of skilled labor as their single biggest obstacle to securing talent. We’re not just competing with other data center companies. We’re competing with manufacturing, energy, semiconductor fabrication, telecom, and other industries attempting to hire from the same skilled labor pool.
So how are we responding?
First, we’ve had to widen the lens on where talent comes from. Great data center talent doesn’t always come from data centers. Some of the best candidates have transferable experience from adjacent industries — including military service — and bring the technical skills, discipline, and problem-solving ability needed to succeed in mission-critical environments.
Second, we’re spending more time building relationships before roles open. In fast-growth markets, reactive hiring isn’t enough. We’re investing in talent pipelines, workforce partnerships, and stronger connections with trade schools, technical programs, and local communities.
Our Critical Facility Manager there made a direct case for the economics: A student who joins the International Brotherhood of Electrical Workers (IBEW), completes trade training, and enters the workforce in four years can come out earning close to six figures, often with better long-term stability than a peer who spent the same four years accumulating college debt.
In Culpeper, Virginia, we partnered with the local career and technical education school, which happens to sit directly across the street from our data centers currently under construction. Over two days, 40 electrical students experienced the full arc of a data center career — from their own lab model of a data hall, to a live construction site, to a fully operational facility in Ashburn — hearing directly from construction managers and technicians about how their training maps to real careers. That kind of experience doesn’t come from a job posting.
Ultimately, these programs are a long-term investment in the workforce this industry will require.
The Stakes Are Real
The scale of what’s coming makes this more than a long-term investment. It’s an immediate operational priority. DataBank’s construction leadership has noted that peak crew sizes on major data center builds have grown from roughly 750 workers to 4,000 or more on a single campus. The second half of 2026 into 2027 will see massive capacity activation across the country, and the industry simply doesn’t have enough qualified workers to meet that demand.
The operators who secure skilled labor now, through early contractor commitments, trade school partnerships, and creative workforce strategies, will have significant advantages over those waiting until projects break ground.
Telling a Better Story
Just as importantly, we’re focused on telling a better story about these careers.
For too long, skilled trades have been overlooked in conversations about the future of work. These are high-impact, well-paying, highly technical roles with real long-term opportunity. In many ways, they are some of the most future-proof careers out there.
What’s happening in data centers is bigger than a hiring challenge. It’s a shift in how we value skilled labor and infrastructure talent. The companies that recognize that — and act on it — will be in the best position to grow.
Because at the end of the day, the future of digital infrastructure depends on the people who build it, power it, and keep it running.
Every compliance audit eventually arrives at the same question: Who can access what, and how do you know? For organizations managing sensitive data — cardholder information, patient records, federal contract data, proprietary systems — the answer lives in network architecture, not just in policy documents or perimeter defenses. For most organizations, that answer starts with network segmentation.
The pressure to get it right has intensified. PCI-DSS, HIPAA, FedRAMP, NIST, CMMC, and ISO 27001 all address segmentation directly, and recent framework updates have raised the bar on what “addressed” actually means. Auditors are no longer satisfied with evidence that controls exist. They want proof that controls work, that they’re tested, and that the documentation reflects the environment as it actually operates, not as it was designed three audits ago.
What Network Segmentation Does, and Why Compliance Frameworks Require It
At its most basic, network segmentation means creating boundaries within a network so that traffic between zones is subject to explicit rules. For example, a server handling payment transactions should not have open access to HR systems, or a guest wireless network should not reach production infrastructure. Segmentation enforces those separations at the network level, independent of whether individual systems or users are behaving as expected.
Organizations implement network segmentation in several ways. VLANs are the most common starting point, logically separating traffic within a physical network without requiring separate hardware for each zone. Firewalls and access control lists define what can pass between segments, and the most defensible implementations follow a deny-by-default posture: Only traffic explicitly permitted passes. More mature environments push controls to the workload or application level, limiting lateral movement even within a segment, a practice known as microsegmentation.
Compliance frameworks require segmentation for practical reasons — not because it is a perfect control, but because it shrinks the attack surface and contains the blast radius when something goes wrong. An attacker who compromises one zone should not be able to move freely into another. A misconfigured system in a development environment should not be able to reach production data. Network segmentation is what makes those boundaries enforceable.
When the Proof Doesn’t Match the Practice
Most organizations already have segmentation in place. Firewalls, VLANs, routing controls, and security groups get implemented as standard practice. The audit problem comes later, when those controls need to be explained to someone who wasn’t in the room when they were built.
Auditors don’t evaluate intentions. They evaluate evidence, and the evidence they’re typically handed doesn’t hold up: network diagrams that no longer match the production environment, firewall rules that have evolved through dozens of undocumented changes, and policies that describe segmentation differently than it is actually implemented. The architecture plan may have been sound, but the documented record of it isn’t.
The most common documentation failures auditors encounter include:
Network diagrams that reflect the original design rather than the current state
Firewall rules with no change history or rationale
Policies that describe intended segmentation but don’t map to actual configurations
Undocumented exceptions that accumulated over time without review
Closing that gap requires treating documentation as an ongoing operational record, not an audit deliverable. Organizations that automate the process, flagging configuration changes as they occur, and triggering documentation updates in real time, spend far less time in remediation and far more time in control.
What the Major Frameworks Are Actually Asking
Regulated organizations rarely answer to a single framework, and the segmentation requirements across them are not identical.
However, they share a common thread: demonstrating that sensitive systems, users, and data are appropriately isolated from less-trusted environments, and that the controls enforcing that isolation are tested, documented, and up to date.
PCI DSS v4.0 requires organizations using segmentation to reduce their cardholder data environment scope to validate and penetration-test segmentation boundaries regularly, not just assert that they exist.
FedRAMP Moderate and High require boundary protection, information flow enforcement, tenant isolation, and logical separation of systems handling federal data.
NIST SP 800-171 and CMMC focus on protecting Controlled Unclassified Information through boundary protection and controlled access between systems. CMMC adds third-party assessment requirements that make documentation accuracy a compliance dependency, not just a best practice.
HIPAA increasingly requires healthcare organizations to isolate systems containing electronic protected health information from broader corporate environments. Recent enforcement actions have made the stakes concrete.
ISO 27001 frames segmentation around trust levels, risk profiles, and business requirements — a more flexible model, but one that still demands evidence of deliberate design.
The specific requirements vary, but the burden of proof does not.
When Segmentation is Done Right
The audit question is consistent across all of them: not whether segmentation exists, but whether it can be demonstrated.
A well-designed segmentation strategy aligns business functions, security requirements, and compliance obligations around a single organizing principle: systems and data that serve different purposes, carry different risk profiles, or operate under different regulatory requirements should not share the same network trust zone.
In practice, that means firewalls operating on a deny-by-default basis, permitting only the traffic a given workflow actually requires. A database server receiving application traffic might be configured to accept only the specific protocol and port that the application uses, and nothing else gets through.
Vendors and contractors present a similar opportunity for precision. Rather than granting broad network access to outside parties, organizations can provision VPN access scoped only to the specific IP addresses and subnets a vendor needs. A field technician replacing cameras has no reason to reach a financial database, and a well-segmented network makes sure they can’t.
Firewall rules with “allow any” configurations, undocumented exceptions that accumulated through years of one-off requests, and architectures where no one can clearly explain why specific traffic is permitted are all signs that segmentation exists in name but not in practice. The test is not whether zones are defined. It is whether anyone can explain, document, and defend what moves between them.
When Engineering and Compliance Don’t Speak the Same Language
Engineering teams and compliance teams are solve different challenges, even when they’re working on the same problem. Engineers focus on implementation: Firewalls are configured, VLANs are in place, and cloud security groups are set. From a technical standpoint, the segmentation works. Compliance teams, however, need documented evidence showing what is segmented, why it is segmented, and how controls are validated.
That gap has a cost. Configuration changes go undocumented. Compliance teams discover during audit prep that the environment has drifted from what the policies describe. By then, the remediation work is unavoidable.
The organizations that avoid this tend to have one thing in common: Someone, or some function, that understands both worlds well enough to translate between them, not to own the work, but to make sure that a technical decision and its compliance implication are understood by both sides at the same time. When that relationship works, it changes the nature of audit preparation entirely, from a scramble to reconcile documentation with reality, to a process that stays current because the two were never allowed to diverge.
The Right Infrastructure Makes This Easier
The organizations that get this right treat documentation not as a deliverable but as a byproduct. Configuration changes generate audit trails automatically. Network diagrams stay current because the systems managing them keep them that way, not engineers responding to audit requests. The alternative is what most regulated organizations already know too well: technical teams pulled from real work to reconstruct documentation, and compliance teams building their case from evidence that was already outdated when they received it.
Network segmentation done well is not a one-time project. It requires architecture that was designed with isolation in mind, documentation that stays current as environments change, and the organizational alignment to make sure technical decisions and compliance obligations move together.
For mid-to-large enterprises in regulated industries, that work is hard enough without fighting the infrastructure underneath it. Colocation environments built to support complex segmentation architectures, with the technical depth to help organizations implement and validate controls across frameworks, remove a layer of friction that most compliance teams would rather not carry.
Some workplace initiatives fade after the first year. The DataBank Cares Kindness Kit program has done the opposite. Each spring, DataBank employees across multiple cities come together to assemble care packages filled with personal hygiene and household essentials, then donate them to local shelters, recovery programs, and advocacy organizations serving women, children, and individuals in need.
DataBank employee-owners in Houston, Dallas, Salt Lake City, and Denver assembled 852 Kindness Kits for organizations serving women, children, and individuals in need.
What began as a modest single-city effort has grown into one of DataBank Cares’ signature annual campaigns, reaching more volunteers, more markets, and more people with each passing year.
This spring brought the program’s strongest results yet. Across four metro markets — Houston, Dallas, Salt Lake City, and Denver — 83 DataBank volunteers assembled and donated 852 Kindness Kits, contributing 216 volunteer hours in the process. Employees also donated or helped secure nearly $2,500 in goods and financial support for partner organizations.
Three Years and Growing
Now in its third consecutive year, the DataBank Cares Kindness Kit program continues to grow. Employees assembled 340 kits in 2024, 650 in 2025, and 852 this year, representing more than 150% growth over two years.
That momentum reflects expanding participation across DataBank markets and the energy of employee resource groups (ERGs) like the Women of DataBank, one of several ERGs that channel employee passion into community action. From the Veterans Network and Volunteer Corps to the Multicultural Group and Pride at DataBank, these ERGs give employees a structured way to lead meaningful initiatives beyond the workplace.
This year’s kits reached four organizations doing vital work in their communities:
Houston Area Women’s Center (Houston): HAWC provides crisis intervention, counseling, and shelter services for survivors of domestic violence and sexual assault. This year, 22 DataBank volunteers showed up with 300 Kindness Kits and 44 hours of their time.
Children’s Advocacy Center of Collin County (Dallas): The center serves children who have experienced abuse and trauma. Dallas fielded the program’s largest volunteer turnout, with 25 employees contributing 100 hours alongside 202 donated kits.
Alpine Recovery Lodge (Salt Lake City) Alpine Recovery Lodge supports women on the path to recovery from addiction. Twenty-six Salt Lake City volunteers dedicated 52 hours and delivered 300 kits to the organization.
Hope House Colorado (Denver) Hope House empowers young mothers living in poverty through education and wraparound support services. Ten Denver volunteers contributed 20 hours and donated 50 kits to the cause.
Together, these four organizations represent the range of need that exists in the communities surrounding DataBank’s facilities. They also reflect a shared belief among DataBank employees: that showing up for neighbors matters, whether that means powering critical infrastructure or assembling a care package for someone who needs one.
Community Is Part of the Infrastructure
Kindness Kits are one expression of a larger commitment that shows up across DataBank’s markets in different forms throughout the year.
Atlanta career exploration: DataBank’s Atlanta campus hosted a career exploration event for local young people, showcasing the diverse, high-paying opportunities available in the data center industry beyond traditional college pathways.
The numbers tell part of the story. The rest belongs to the 83 DataBankers who gave their time this spring to make sure 852 people received something they needed.
Want to learn more about how DataBank is investing in the communities where we operate? Visit our Community Relations page or explore DataBank Digest for more stories about our people, our partners, and the neighborhoods we’re proud to call home. Read more about our DataBank Cares programs.
