AF Form 3215, the Communication System Requirements Document, is how an Air Force unit formally asks for new IT capability or a change to existing communications infrastructure. Download the current version from the Department of the Air Force e-Publishing site at e-publishing.af.mil, complete the requester blocks (particularly the requirement and justification), and route it through your unit point of contact to the base Communications Systems Officer, who fills in the technical solution and moves it up the approval chain. The form has 14 numbered blocks, and how carefully you write blocks 7 and 8 largely determines whether your request moves in weeks or stalls for months.
Where to Get the Form and the Governing Instruction
Go to e-publishing.af.mil, search “3215” in the forms tool, and download the PDF. The instruction that governs how communications requirements are developed and processed, including detailed guidance for completing this form, is AFI 33-103, Requirements Development and Processing.
Many installations now handle requirements through the Cyberspace Infrastructure Planning System (CIPS), which may auto-populate certain fields and lets multiple stakeholders track status in real time. CIPS mirrors the same data the paper form captures, so understanding each block still matters even if you never touch the PDF.
What Goes in Each Block
You complete some blocks yourself; others are filled in by the Communications Systems Officer (CSO) and approval authorities after you submit. Work through them in order.
- Block 1, Date: the date you prepare or submit the form.
- Block 2, CSO Control Number: leave blank. The CSO assigns a tracking number when the request arrives.
- Block 3, Requirement Title: a short, descriptive title. “Building 400 Network Switch Upgrade” reads better than “IT Requirement.”
- Block 4, Date Needed: when you need the capability operational. Be realistic. An artificially early date will not accelerate the process and can get the request flagged for re-evaluation.
- Block 5, Mission or System Supported: the major command, control, communications, and computer system or specific mission the requirement supports.
- Block 6, Requesting Agency Point of Contact: someone who can discuss the requirement in detail during technical review. Include name, office symbol, phone, and email.
- Block 7, Requirement: the most important block on the form. State the capability in functional terms, describing what the system needs to do rather than a brand or model. If you do recommend specific equipment, explain why. Note security handling requirements, whether a secure or classified capability is needed, and any special conditions such as accommodations for users with disabilities, unusual operating environments, or training and maintenance needs.
- Block 8, Justification: why you need it. This is your mission impact statement. Tie the request to operational readiness and explain what happens if it goes unfulfilled. Strong justifications win priority when resources are limited.
- Block 9, CSO’s Proposed Solution/Alternatives: completed by the CSO after reviewing the requirement. Additional pages may be attached for complex solutions.
- Block 10, Technical Solution Authority: identifies who certified that the proposed solution meets architectural and interoperability standards. The CSO ensures this block gets completed, though other activities may provide the certification.
- Block 11, Records Management Approval Authority: required when the request involves information management systems, records management, reports control, or Privacy Act and Freedom of Information Act data. The information management function must sign off here.
- Block 12, Requester Approval Authority: you complete this after the CSO returns the proposed solution. Approve or disapprove it and indicate whether funds are available. Local or Major Command procedures may require higher approval for requests above a certain dollar amount.
- Block 13, Host Base Approval Authority: used when local or Major Command guidelines route the request to that level.
- Block 14, MAJCOM Approval Authority: used when the form must be forwarded to the Major Command for review or action.
Write block 7 as if the reader has never set foot in your work center. Describe the environment, the user count, the data classification, and the operational gap. A vague requirement forces the CSO to come back with questions, and every round of questions delays everything downstream.
Classification and Funding Details
Inside block 7, specify whether the data the system will process is unclassified, controlled unclassified, or classified at a higher level. Classified installations are treated as non-routine and take significantly longer, so flagging that up front prevents surprises.
Before answering the funding question in block 12, coordinate with your unit resource advisor to confirm the source. Common vehicles include Operations and Maintenance funds and Military Interdepartmental Purchase Requests. Identifying the specific budget line lets the finance office track the obligation once approval lands. Requests submitted without a clear funding answer tend to sit until someone chases down the money.
Attachments and Companion Forms
If the system will collect, maintain, or disseminate information in identifiable form (data tied to specific people), you may need to submit a Privacy Impact Assessment (PIA) with the AF Form 3215. The E-Government Act of 2002 requires a PIA whenever a federal agency develops or procures IT that handles personally identifiable information, and AFI 33-332 extends that requirement to substantial changes to existing systems that manage such data. Check with your unit privacy monitor early. A missing PIA can halt an otherwise complete request.
If the work involves construction and needs Civil Engineering Squadron coordination, plan on filing a companion AF Form 332 alongside the AF Form 3215. That adds a scheduling layer, so build it into your timeline.
New IT systems connected to the Air Force network must clear the Risk Management Framework (RMF) under AFI 17-101 before going live. You do not need to complete RMF before submitting the AF Form 3215, but if the system has no existing authorization to operate, the RMF timeline runs on top of the procurement timeline. For commercial off-the-shelf software, check whether it already carries an Authority to Operate or sits on an approved product list, which can save months. Note any of this in block 7 so the CSO can plan a realistic schedule.
How the Form Routes After You Submit
Your first stop is the unit-level point of contact for communications requirements. At many installations, requests for computers, software, and network services route through the unit Telephone Control Officer, while cell phones, wireless devices, and air cards go through the unit Personal Wireless Communication System manager. These POCs verify the form is complete and correctly formatted before forwarding it to the base Communications Squadron or CSO.
The CSO conducts the technical review, fills in block 9, evaluates your stated need against existing infrastructure, and checks the proposed solution against the broader Air Force network architecture. If the solution needs resources or approvals beyond the base, the form moves to the Host Base approval authority in block 13 and, when required, to the Major Command in block 14. Bases running CIPS track all of this in the system rather than by paper handoff.
How Long It Takes
Routine requests, meaning phone and network installations, line relocations, and service activations, typically run 45 to 60 days. Non-routine requirements, including large-scale projects, infrastructure upgrades, new software approvals, and classified system installations, run six to 12 months.
Those windows assume a clean submission. Incomplete blocks, weak justifications, or unclear requirements cycle the form back for correction and push the timeline out further. Adding a companion AF Form 332 or triggering RMF authorization stretches it further still.
Changing or Cancelling a Request After Submission
If scope changes after you submit, whether new technical specs, a different installation location, or a larger quantity of equipment, file a revised AF Form 3215 detailing the modifications. A formal amendment keeps the technical solution aligned with what actually gets built and prevents the funding authorization from going stale.
When a mission change eliminates the need, notify the tracking authority so the record can be closed in CIPS or whatever tracking system your base uses. Closing out a cancelled requirement releases any earmarked funds back to the general budget and keeps the planning database from filling with dead entries that distort resource projections for active projects.