CRE
A site exception should override a portfolio technology standard when applying the standard would create a documented operational, safety, regulatory, contractual, carrier, or lifecycle risk greater than the risk of an approved alternative. The exception needs an owner, compensating controls, and a scheduled review date.
What makes a site exception legitimate rather than a preference?
"Cain responds quickly, knows his stuff, and solves problems fast. He never makes me feel behind on technology."
Harold, Chambliss Media Group
A portfolio standard gives owners and property teams a repeatable way to support, secure, document, and replace technology. It reduces avoidable variation across sites, simplifies vendor coordination, and gives decision-makers a clearer view of risk and cost.
Consistency is valuable, but it should not force a building into a design that does not fit its physical infrastructure, contractual obligations, or operational dependencies. A standard is a decision framework, not a reason to ignore what the site actually requires.
A legitimate exception starts with a specific, verifiable constraint. That may be an inherited carrier service, a landlord-controlled network, a life-safety dependency, a lease commitment, a telecommunications-room limitation, or a building system that cannot safely move to the standard design without remediation.
Preference does not meet that test. A familiar vendor, a tenant request, or resistance to change may deserve consideration, but none is enough on its own. The request should show why the standard would create more business risk, disruption, cost, or noncompliance than the proposed alternative.
In Atlanta, older office properties can have crowded risers, undocumented carrier additions, limited telecom space, and building systems added over many years. A newer mixed-use property may have different constraints. The evaluation should begin with the building's facts, not an assumption that every site can be treated the same way.
The takeaway: approve exceptions for documented constraints, not convenience or vendor habit.
Which site conditions can justify overriding the standard?
An exception can be appropriate when a building has a technical, physical, or contractual dependency that makes the standard impractical or unsafe to apply immediately. The goal is not to overlook the dependency. It is to identify it, assign ownership, and determine whether it is temporary, long-term, or evidence that the standard needs another approved design option.
| Exception driver | Why it may justify an override | Evidence needed before approval |
|---|---|---|
| Life-safety or emergency communications dependency | A change could affect systems supporting emergency response, notification, detection, or egress. | System documentation, applicable requirements, vendor input, testing scope, and a controlled change plan. |
| Carrier or demarcation constraint | The existing handoff, pathways, or service arrangement may not support the standard without construction or a service transition. | Carrier inventory, demarcation details, pathway review, service terms, and implementation impact. |
| Inherited building technology | Building controls, access control, cameras, or other connected systems may depend on a design that cannot safely change immediately. | Dependency map, network assessment, vendor requirements, segmentation approach, and lifecycle recommendation. |
| Lease, tenant, or ownership obligation | The property may be committed to a service, access method, or technology arrangement that cannot be changed unilaterally. | Contract or lease review, responsibility boundaries, operating impact, and transition date. |
| Physical infrastructure limitation | Riser capacity, pathways, power, cooling, room space, or cabling conditions may prevent a compliant deployment. | Assessment findings, available drawings, remediation scope, and budget alternatives. |
| Regulatory or insurer requirement | The site may require a control or record beyond the portfolio baseline. | Documented requirement, affected systems, control owner, and evidence-retention approach. |
Life-safety dependencies require particular discipline. Not every connected security or building system is life safety, but a system involved in emergency notification, response, detection, or egress should be classified before a portfolio change proceeds. The team needs to know who owns the system, what change control applies, and how testing will be completed.
Carrier constraints also need precise language. The provider's demarcation point is not automatically the main telecom room or the minimum point of entry. Responsibility depends on the service arrangement and the facility design. A site assessment should establish the actual handoff and the work required to change it.
The takeaway: an exception is justified when a documented site dependency outweighs the value of uniformity.
How should Atlanta property teams evaluate an exception before approving it?
Start with a site assessment that separates known facts from assumptions. Review carrier services, network equipment, telecommunications rooms, risers, cabling pathways, physical-security systems, building controls, connected devices, vendor relationships, and available documentation. Missing documentation is a finding that needs resolution, not a reason to approve a vague exception.
Next, define the business outcome at risk. Ask what happens if the portfolio standard is applied exactly as written. Could tenants lose service during a transition? Could engineering lose visibility into building controls? Would a carrier change require unplanned pathway work? Would the new design introduce a support gap or expand cyber exposure?
Then compare two controlled paths: adoption of the standard with the remediation it requires, and a managed exception with explicit safeguards. Compare operational disruption, security architecture, maintenance ownership, vendor support, documentation needs, expected lifecycle, cost responsibility, and the next point at which the decision will be reviewed.
Do not reduce the decision to "new versus old" or "centralized versus local." The right question is whether each option has a clear owner, a defensible risk position, and a workable operating model for the building.
Network-connected physical systems need additional scrutiny. Cameras, access-control components, controllers, and building-management devices often have different availability needs, vendor support practices, and replacement cycles from ordinary office endpoints. Their network access should be designed around the role they perform, not treated as an afterthought.
A site exception should have one accountable owner, one documented rationale, and one scheduled review date.
For properties in Midtown, Buckhead, and the Perimeter market, a useful review combines the technology inventory with real operating conditions: tenant access, carrier work windows, vendor access, maintenance schedules, construction plans, and future buildouts. A spreadsheet alone rarely captures those dependencies.
The takeaway: assess the building's real dependencies before selecting the portfolio's preferred technical answer.
How do you keep a justified exception from becoming unmanaged risk?
An approved exception should become a governed record, not an email thread that disappears after the project closes. Record the affected site, systems in scope, business rationale, technical rationale, approval authority, risk owner, compensating controls, vendor contacts, documentation location, and review date.
Compensating controls should address the difference between the exception and the portfolio baseline. A legacy building system may need network segmentation, restricted vendor access, stronger identity controls, additional monitoring, a documented recovery process, or an earlier replacement milestone. Adding a generic security product without addressing the specific gap does not govern the risk.
Cyber risk management means identifying, assessing, prioritizing, treating, monitoring, and communicating risk. It does not require eliminating every risk. It does require making accepted risk visible, assigning responsibility for it, and reducing it where practical.
Project coordination is equally important when an exception crosses multiple owners. A technically sound decision can still fail if no one manages carrier timing, construction access, tenant notices, testing, acceptance criteria, documentation updates, and transition ownership.
Set a calendar review date and event-based review triggers. A lease renewal, carrier-contract expiration, major tenant buildout, capital project, security incident, system failure, vendor end-of-support notice, or building renovation should reopen the exception for review.
The takeaway: an exception is controlled only when its risk, ownership, safeguards, and exit path remain visible.
When should repeated site exceptions change the portfolio standard?
A portfolio standard should evolve when the same exception appears repeatedly, when it addresses a recurring building condition, or when technology changes make the original design less effective. Repeated exceptions often show that the standard is too narrow, outdated, or missing an approved decision branch.
Do not wait for every property to look alike before improving the standard. A stronger framework can include approved patterns for older assets, constrained risers, landlord-managed networks, tenant-heavy properties, or buildings with specialized physical-security and operational-technology dependencies.
Separate a one-off legacy condition from a repeatable operating model. If several properties need the same alternate carrier handoff, the portfolio may need a documented approved pattern and a consistent evidence checklist. If one property has a unique access-control dependency that will disappear during modernization, maintain a limited exception with a retirement milestone.
Budget planning is a practical time to make this decision. Property operations can explain the day-to-day impact, while ownership and asset teams can weigh capital priorities, risk, tenant expectations, and long-term operating costs. Both perspectives matter because technology exceptions affect both building performance and financial planning.
GDS Technology supports commercial property teams with technology assessments, network discovery, cybersecurity review, physical-security review, carrier inventory, telecom-room and riser assessments, infrastructure remediation, and project coordination. The objective is a defensible operating standard that helps the property move forward without ignoring site-specific risk.
The takeaway: recurring exceptions are useful feedback that the portfolio standard may need a better-approved option.
For more on this, see Riser Management Services, IT Support for Commercial Real Estate in Atlanta and Disaster Recovery Planning Services in Atlanta.
Frequently Asked Questions
Who should approve a site exception to a portfolio technology standard?
Approval should include the accountable business owner, the technology owner, and the person responsible for affected property operations or systems. Include security, facilities, leasing, carrier, or vendor stakeholders when their responsibilities are directly affected. The approval record should identify who accepts the remaining risk and who owns the scheduled review.
Can a legacy building system justify a permanent exception?
Yes, but only when its dependencies, support model, risk controls, and lifecycle plan are documented. Legacy status alone is not a justification. A long-term exception still needs review triggers because vendor support, security exposure, tenant requirements, carrier arrangements, and available modernization options can change over time.
How long should a technology exception stay in place?
The duration should follow the underlying condition rather than an arbitrary deadline. Tie it to a lease renewal, carrier contract end, planned renovation, vendor support milestone, or capital project. If no known event exists, set a review date and document the information needed to establish a practical exit path.
Does an exception mean the site can ignore cybersecurity standards?
No. An exception may change the technical implementation, but it does not remove accountability for cyber risk. Identify the security difference, assess the exposure, and apply appropriate compensating controls. Those may include segmentation, identity controls, vendor-access restrictions, monitoring, documentation, recovery planning, or a defined modernization timeline.
