.svg){kind=logo}
You’re three weeks from your SOC 2 audit and the auditor’s pre-check list arrives. Buried in the middle: “network security policy, approved, current version.” You check your shared drive. There’s a firewall config export from 2021, a network diagram someone drew in Lucidchart, and a note that says “TODO: write network policy.” Not quite the same thing.
A network security policy is a formal document that defines how your organisation protects its networks, systems, and data from unauthorised access, misuse, and attack. It sets the rules for who can connect to your network, what devices are allowed, how traffic is monitored, how the network is segmented, and what happens when something goes wrong. It doesn’t replace your firewall or your VPN. It governs them.
The policy applies to everyone with network access: employees, contractors, and third-party vendors. It covers internal networks, cloud environments, remote connections, and guest Wi-Fi. The named owner is typically your CISO, IT Security Manager, or CTO if you’re a smaller company.
Every major compliance framework expects one:
- SOC 2 (CC6.6, CC6.7): logical access restrictions and protection against external threats
- ISO 27001 (Annex A 8.20, 8.21, 8.22): documented network controls, service security requirements, and network segmentation
- HIPAA (Technical Safeguards, §164.312): network access controls and transmission security for ePHI
- NIST CSF (PR.AC-3, PR.AC-5, PR.PT-4): remote access management, network integrity protection, and communications security
By the end of this guide, you’ll know exactly what to put in your network security policy, have a free template you can adapt today, and understand how it maps to the frameworks you’re working toward.
Here’s what I’ll cover:
- What a network security policy is and what it needs to include
- A free, complete template with pre-populated content
- How to implement and enforce it step by step
- How it maps to SOC 2, ISO 27001, HIPAA, and NIST
- What evidence auditors expect to see
- Common mistakes and how to avoid them
I’ve reviewed hundreds of these policies across SOC 2 and ISO 27001 audits. Most gaps aren’t in the technical controls. They’re in the missing document that should govern them.
What Is a Network Security Policy?
A network security policy is the document that defines the rules governing how your organisation’s networks are secured, accessed, monitored, and maintained.
Key insight
You can have the most sophisticated firewall on the market, but if there's no approved document defining what it's supposed to block and why, an auditor has nothing to evaluate against.
It’s not your firewall ruleset. It’s not your network diagram. Those are controls: the technical implementation of the rules. The policy is the document that decides what those rules are and who is accountable for them. You can have the most sophisticated firewall on the market, but if there’s no approved document defining what it’s supposed to block and why, an auditor has nothing to evaluate against.
A network security policy typically covers:
- Who can access the network and under what conditions
- Which devices are permitted to connect
- How remote access is managed and secured
- How network traffic is monitored and what triggers an alert
- How the network is segmented to isolate sensitive systems from everything else
- What happens when someone violates the rules
Who Owns a Network Security Policy?
The policy needs a named owner. At most companies, that’s the CISO, IT Security Manager, or CTO. In smaller startups, it’s often the person who also owns the SOC 2 programme.
Without a named owner, two things happen: the policy never gets updated after the first draft, and when an auditor asks “who is responsible for network security?”, the answer is a long silence. Neither is a good outcome.
Who Does It Apply To?
Everyone who touches the network. That means:
- All full-time employees
- Contractors and consultants with network access
- Third-party vendors connected to your systems
- Developers working in cloud environments
- Anyone connecting remotely via VPN or accessing internal systems from outside the office
Choosing a Network Security Policy Framework
Most companies don’t write their network security policy from a blank page. They start with a recognised network security policy framework and adapt it to their environment.
The most commonly used frameworks as a structural base:
- NIST SP 800-53 (AC and SC control families): detailed access and network protection controls, widely used in US federal and enterprise environments
- ISO 27001 Annex A (8.x): structured network controls tied directly to your ISMS, required if you’re pursuing ISO 27001 certification
- CIS Controls (Control 12, Network Infrastructure Management): practical controls for managing network access and segmentation
Pick the framework that matches your compliance target. SOC 2 maps well to NIST. ISO 27001 has its own structure. HIPAA has specific Technical Safeguard requirements that define the floor.
Policy vs. Controls: Why You Need Both
This distinction matters in audits.
The policy defines the rules: “all remote access must go through an MFA-protected VPN.” The control is the technical implementation: the VPN system, the MFA configuration, the access log.
Auditors expect both. A control without a corresponding policy clause is unreviewable. The auditor can see the VPN exists, but they can’t evaluate whether it’s configured correctly against your stated requirements. A policy clause without a working control is just words. You need both sides.
Why Your Business Needs a Network Security Policy
I’ve read a lot of post-breach incident reports. The pattern that shows up most often isn’t a zero-day exploit or a sophisticated attacker. It’s a misconfigured rule. A port that was opened for a vendor and never closed. A VPN account for a contractor who left six months ago. An alert threshold set too high to catch anything useful.
Free Demo
Stop losing enterprise deals over a missing network security policy.
ComplyJet documents, approves, and maps to SOC 2, ISO 27001, and HIPAA in minutes.
These aren’t technical failures. They’re governance failures. And a network security policy is how you prevent them.
Network Security Policy Best Practices
Before the frameworks and compliance checklists, here are the principles that separate policies that work from ones that gather dust:
- Tie every rule to a named owner. If nobody owns it, nobody enforces it.
- Write for your actual architecture, not a generic template. A cloud-first startup and an on-prem enterprise have different risks and different controls.
- Treat acknowledgement as evidence, not a formality. Every employee and contractor should confirm they’ve read and understood the policy.
- Build in an exception process before you need one. The first time you need an exception is the wrong time to design the process.
- Schedule the annual review before the year starts. Don’t wait until three weeks before an audit.
- Treat incidents as review triggers. Annual review is the minimum; a major incident or architecture change should kick off an out-of-cycle review.
There are three reasons every company with network access needs this policy:
Security risk. Without defined rules, network access is ungoverned. Employees connect personal devices. IT has no baseline to audit controls against. Attackers exploit the gap between what’s intended and what’s actually in place. A policy doesn’t prevent all attacks, but it closes the gaps that come from unclear accountability.
Compliance requirements. SOC 2, ISO 27001, HIPAA, and NIST CSF all explicitly require documented network security controls backed by an approved policy. Having a working firewall is not enough. The policy must exist, be formally approved, and be communicated to the people it applies to.
Operational clarity. When a network incident happens, the policy defines who does what: who isolates the affected segment, who reviews the logs, who notifies the CISO. Without it, your incident response is improvised and your audit evidence is a mess.
Auditors don’t just check whether you have firewall rules. They check whether those rules are backed by a document your team has signed off on and actually follows.
Which Organisations Need a Network Security Policy?
I’ve had founders tell me “we’re a 12-person startup, we’re all on Slack, we don’t really have a network.” Then they apply for SOC 2 and discover that their AWS VPC, their Cloudflare setup, and their VPN are all part of their network, and an auditor expects documented rules governing all of it.
Why it matters
If your company has systems that connect to the internet and employees who access those systems, you need a network security policy.
The short answer: if your company has systems that connect to the internet and employees who access those systems, you need a network security policy.
More specifically:
Any company pursuing SOC 2, ISO 27001, or HIPAA. All three frameworks explicitly require documented network access controls and a supporting policy. This isn’t optional; it’s a stated requirement.
SaaS companies handling customer data. Enterprise buyers routinely include network security documentation requests in security questionnaires. If you don’t have a policy, you lose deals.
Healthcare vendors and covered entities. HIPAA Technical Safeguards (§164.312) require documented controls around network access to systems containing electronic protected health information. A HIPAA network security policy isn’t optional for anyone touching ePHI.
Remote-first companies. When your team works from 15 different locations, the corporate network perimeter is effectively everywhere. A policy is the only way to govern it consistently.
B2B companies selling into regulated industries. Finance, healthcare, and government customers will audit you too. A network security policy is table stakes for enterprise sales.
Building a Company Network Security Policy from Scratch
Even a 10-person startup pursuing SOC 2 needs a documented network security policy. It can be shorter and simpler than an enterprise policy. Four pages covering the essentials is better than a 40-page document nobody reads.
What matters at the startup stage:
- It exists and has been formally approved by someone with authority
- It’s been communicated to everyone who accesses the network
- You’ve collected acknowledgements you can show an auditor
- It names an owner who will update it when things change
Starting early also means you have a review history to show. A policy dated the week before your audit looks different from one with two annual reviews already on record.
Key Network Security Policy Guidelines and Components
Most network security policies I’ve seen fail in one of two directions. Either they’re too vague (“we will protect our networks using appropriate controls”), or they’re too technical (a firewall ruleset export dressed up with a header that says “Policy Document”). Neither works in an audit.
A good network security policy sits between the two: specific enough to be auditable, clear enough to be understood by the people it governs. See Section 6 for a complete network security policy example you can adapt. The network security policy sample and template there cover all the components below.
Here’s what a complete policy needs to include:
| Policy section | What to include |
|---|---|
| Purpose | Why this policy exists; which risks and compliance requirements it addresses |
| Scope | Which networks, systems, and people are covered; what’s excluded |
| Roles and responsibilities | Network policy owner, IT/security team, employees, contractors, third parties |
| Network access controls | Who can access what; authentication requirements; least privilege principle |
| Device security standards | Approved device types; endpoint requirements; BYOD rules |
| Network segmentation | Production, staging, dev, corporate, guest, and DMZ separation rules |
| Remote access | VPN requirements; approved tools; prohibited protocols |
| Wireless network security | Corporate Wi-Fi standards; guest network isolation; prohibited access points |
| Monitoring and logging | What gets logged; retention period; alerting thresholds; who reviews |
| Firewall and perimeter controls | Baseline ingress/egress rules; approved ports; change management process |
| Incident response integration | How network events feed into incident response; escalation path |
| Third-party and vendor access | Vendor access restrictions; approval process; time-limited sessions |
| Exceptions | How to request and document policy exceptions; who approves |
| Review cadence | Annual review minimum; trigger events for out-of-cycle review |
| Enforcement | Consequences for violations; how violations are detected and escalated |
Network Security Policy Guidelines for Access, Segmentation, and Monitoring
Three areas trip people up most often.
Access controls. “Use strong authentication” is not a policy requirement. “All remote access must use an MFA-protected VPN; direct RDP and SSH access from outside the corporate network is prohibited” is. Be specific about protocols, tools, and what’s explicitly prohibited.
Network segmentation. Production systems must be isolated from development and staging environments. Customer data must not be reachable from the guest network. These need to be explicit clauses in your policy, not implied arrangements understood by your infrastructure team.
Monitoring and logging. Define what gets logged (authentication events, network traffic anomalies, firewall rule changes), how long logs are retained (90 days is a common minimum; some frameworks require longer), and who is responsible for reviewing alerts. “We have a SIEM” is not the same as a policy clause that defines how the SIEM is used.
Why Controls Alone Are Not Enough
The table above defines what your policy must address. Your controls (firewall configs, IAM rules, SIEM alerts) implement each clause.
A common audit finding: a control exists with no corresponding policy clause. The VPN is working, but the policy doesn’t say VPN is required. The SIEM is running, but the policy doesn’t define the retention period or who reviews alerts. Auditors need a document to evaluate against. Make sure the document covers everything you’re doing.
Free Network Security Policy Template, Examples, and Sample
Here’s a template you can use today. This network security policy example is adapted from real policies used by SOC 2 and ISO 27001-certified companies. The content is pre-populated wherever possible so you’re not starting from a blank page.
Use [brackets] for values specific to your company: names, tools, thresholds, dates. Everything else should work as written. I’ve also included network security policy examples and notes for cloud-first SaaS environments below key sections.
Free Template
Network Security Policy Template
Ready-to-use, audit-ready. Covers SOC 2, ISO 27001, HIPAA, and GDPR.
[Company Name] Network Security Policy
Version: 1.0 Effective Date: [Date] Owner: [Name, Title] Approved by: [Name, Title] Next Review Date: [Date, 12 months from effective date]
1. Purpose
This policy establishes the requirements for securing [Company Name]’s network infrastructure, including all internal networks, cloud environments, remote access connections, wireless networks, and third-party connections. Its purpose is to protect the confidentiality, integrity, and availability of information assets; prevent unauthorised access to systems and data; and satisfy the network security requirements of applicable compliance frameworks including SOC 2, ISO 27001, HIPAA, and NIST CSF.
2. Scope
This policy applies to all individuals and systems that access [Company Name]’s network infrastructure.
| In scope | Details |
|---|---|
| Personnel | All full-time employees, contractors, consultants, and temporary staff |
| Devices | All company-owned devices; personal devices approved under the BYOD policy |
| Networks | Corporate LAN/WAN, cloud VPC environments, VPN tunnels, wireless networks, guest networks |
| Third parties | All vendors and partners with access to [Company Name] network resources |
| Systems | Production, staging, development, corporate, and management systems |
Out of scope: customer-operated systems not directly connected to [Company Name] infrastructure.
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Network Security Policy Owner ([Name/Title]) | Maintain and update this policy; ensure controls are implemented and effective; own annual review |
| IT/Security Team | Implement and operate network controls; monitor for anomalies; manage access requests |
| All Employees and Contractors | Follow the rules in this policy; report suspected violations or anomalies immediately |
| Third-Party Vendors | Comply with this policy for any access to [Company Name] network resources |
| Legal/Compliance | Review for regulatory requirements; maintain framework control mapping |
4. Network Access Controls
4.1 Authentication requirements
All access to [Company Name] network resources requires individual authentication. Shared credentials are prohibited. The following standards apply:
| Access type | Authentication requirement |
|---|---|
| Corporate Wi-Fi | WPA3-Enterprise with individual credentials; no shared passwords |
| VPN (remote access) | MFA-protected; approved VPN client only: [VPN tool name] |
| Cloud management console | MFA required for all console and API access; no long-lived access keys |
| Production systems | MFA required; access via VPN or bastion host only |
| Guest network | Isolated; internet access only; no authentication to internal systems |
4.2 Least privilege
Access to network resources is granted based on the minimum permissions required for a job function. Network access requests must be approved by [role/title] and reviewed every 90 days. Access is revoked within 24 hours of an employment or contractor engagement ending.
4.3 Prohibited access methods
The following are prohibited without explicit written approval from the Network Security Policy Owner:
- Direct RDP or SSH access to production systems from outside the corporate network or VPN
- Personal VPN services on company-managed devices
- Firewall port-forwarding changes without change management approval
- Peer-to-peer file sharing protocols on corporate networks
- Unencrypted protocols (Telnet, FTP, HTTP) for any remote management task
5. Device Security Standards
5.1 Approved devices
Only devices meeting the following standards may connect to corporate networks (excluding guest Wi-Fi):
| Standard | Requirement |
|---|---|
| Operating system | Current supported OS version; security patches applied within 14 days of release |
| Endpoint protection | Approved EDR tool installed and active: [tool name] |
| Disk encryption | Full-disk encryption enabled (FileVault for macOS; BitLocker for Windows) |
| Screen lock | Automatic lock after 5 minutes of inactivity; password required to unlock |
| Device management | Enrolled in [MDM tool]; compliance posture verified before network access |
5.2 Personal devices (BYOD)
Personal devices may connect to [Company Name] systems only if they meet the device standards above and are enrolled in the BYOD programme. See the [BYOD Policy] for full requirements. Personal devices are prohibited from directly accessing production systems.
6. Network Segmentation
[Company Name]’s network is divided into the following segments. Traffic between segments requires explicit, approved firewall rules and is monitored.
| Segment | Purpose | Access rules |
|---|---|---|
| Production | Live customer-facing systems and data | IT/Security and production on-call only; VPN and MFA required; no direct access from dev or staging |
| Staging | Pre-production testing | Engineering team; VPN required; no real customer data permitted |
| Development | Active development workloads | Engineering team; VPN required; isolated from production |
| Corporate | Internal business tools (email, HR, finance, communication) | All employees; VPN required for remote access |
| Guest | Visitor and contractor Wi-Fi | Internet access only; fully isolated from all internal segments |
| Management | Network infrastructure (routers, switches, firewalls, monitoring) | IT/Security only; MFA required; all access logged |
Network segmentation changes require change management approval and documentation before implementation.
7. Remote Access
7.1 VPN requirements
All remote access to internal systems must route through [Company Name]’s approved VPN. Rules:
- Only the approved VPN client is permitted: [tool name]
- Split tunnelling is prohibited; all traffic must route through the VPN tunnel
- VPN sessions must be MFA-protected
- Session timeout is set to [X] hours of inactivity
- Access is logged; logs are retained for a minimum of 90 days
7.2 Prohibited remote access methods
- Direct internet exposure of internal services without VPN or a Zero Trust gateway
- Consumer remote desktop tools (TeamViewer, AnyDesk) on production systems without IT approval
- Unencrypted protocols for any remote system management
8. Wireless Network Security
8.1 Corporate wireless
- Protocol: WPA3-Enterprise with individual credentials; no shared passphrases
- Separate SSID from guest network
- Rogue access points are prohibited. Suspected unauthorised access points must be reported to IT Security immediately.
8.2 Guest wireless
- Fully isolated from all internal network segments
- Internet access only; [Company Name] internal systems are not accessible from guest Wi-Fi
- Guest Wi-Fi credentials are rotated every [30/90] days
9. Monitoring and Logging
9.1 Events logged
| Event type | Minimum retention |
|---|---|
| Authentication events (success and failure) | 90 days |
| Firewall rule changes | 1 year |
| VPN session logs | 90 days |
| Network access control events | 90 days |
| Privileged access events in production | 1 year |
| Security alert events | 1 year |
9.2 Alerting
The following event types generate real-time alerts reviewed by [IT Security / on-call team]:
- Failed authentication attempts exceeding [5] in [10] minutes from a single source
- Login from a geographic location outside [Company Name]’s normal operating regions
- Firewall rule changes outside approved change windows
- Production network access from an IP address outside the approved allowlist
9.3 Log integrity
Logs are stored in [centralised logging tool]. Write access to logs is restricted to [role]. Logs may not be modified or deleted before the retention period expires.
10. Firewall and Perimeter Controls
10.1 Default deny
The default posture for all firewall rules is deny. Only explicitly approved traffic is permitted. Permitted traffic is documented in the firewall change log.
10.2 Approved inbound traffic
Standard approved inbound: HTTPS (443) for customer-facing services. All other inbound ports require change management approval with a documented business justification.
10.3 Change management
All firewall rule changes must be submitted through [change management tool/process], approved by [Network Policy Owner or designee], and documented with: requesting party, business justification, effective date, and review date. Emergency changes must be documented within 24 hours of implementation.
11. Third-Party and Vendor Access
Third parties requiring network access to [Company Name] systems must:
- Have a current signed data processing or vendor access agreement in place
- Submit an access request to [IT/Security team] with a documented business justification
- Receive time-limited credentials (maximum: 90 days; renewable with re-approval)
- Use MFA-protected, audited access methods only (VPN or Zero Trust gateway)
- Restrict activity to the agreed scope; [Company Name] network access may not be used for any other purpose
Vendor access is reviewed quarterly. Access is revoked within 24 hours of contract termination.
12. Exceptions
Requests to deviate from this policy must be submitted to [Network Security Policy Owner]. Each request must document:
| Exception field | Required content |
|---|---|
| Policy clause | The specific section being excepted |
| Business reason | Why the exception is needed |
| Risk introduced | The security risk created by the exception |
| Compensating control | What alternative control is in place |
| Proposed expiry | Maximum 90 days; renewable with re-approval |
Approved exceptions are logged in [exceptions register]. Exceptions exceeding 90 days require executive sign-off. All exceptions are reviewed as part of the annual policy review.
13. Enforcement
Violations of this policy may result in disciplinary action up to and including termination. Significant violations include:
- Connecting unauthorised devices to the corporate network
- Sharing VPN or network access credentials with other individuals
- Bypassing network monitoring or firewall controls
- Accessing network segments outside your approved scope
- Failing to report a known or suspected network security incident
Suspected violations must be reported to [IT Security / CISO] immediately. Reports made in good faith are protected from retaliation.
14. Review and Updates
This policy is reviewed annually by the Network Security Policy Owner and approved by [Approver role/name]. Out-of-cycle reviews are triggered by:
- A material change to network architecture or cloud infrastructure
- A network security incident or significant audit finding
- A new compliance framework requirement affecting network security controls
- Addition of a major new network segment or remote access method
15. Version History
| Version | Date | Author | Summary of changes |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial version |
How to Write and Roll Out a Network Security Policy
Writing the document is the easy part. I’ve seen companies spend two weeks perfecting the policy text and then skip the steps that make it real. In a SOC 2 audit, a policy that exists but was never communicated is treated the same as a policy that doesn’t exist.
Free Demo
ComplyJet gets your network security policy approved, acknowledged, and audit-ready.
Mapped to SOC 2 CC6.6, ISO 27001 Annex A 8.x, and HIPAA Technical Safeguards — automatically.
Here’s the full rollout:
Assign an owner before anything else. Without a named owner, the policy won’t get finished and won’t get maintained. Name the owner in the document header on day one.
Audit your current network architecture. Before writing rules, map what actually exists: network segments, remote access tools, VPN configuration, cloud VPCs, third-party connections. You can’t govern what you haven’t inventoried.
Customise the template for your environment. Cloud-first is different from hybrid on-prem. The template in Section 6 covers both, but your policy should reflect your actual setup.
Legal or compliance review. If HIPAA or GDPR applies, loop in your legal team before finalising. Framework-specific requirements can change the specifics of what you need to document.
Formal approval. The policy must be approved by someone with authority: typically the CISO, CTO, or equivalent. An unapproved policy is not a policy as far as auditors are concerned.
Communicate it to everyone it applies to. Don’t just post it in a wiki. Email it. Cover it in an onboarding session. Make sure every employee and contractor with network access knows it exists and what it requires of them.
Collect signed acknowledgements. Every employee and contractor with network access should confirm they’ve read and understood the policy. These acknowledgements are evidence, not a formality. Store them somewhere you can retrieve them for an audit.
Map each clause to your compliance framework controls. Tag the relevant sections to SOC 2 CC6.6 and CC6.7, ISO 27001 8.20 through 8.22, or HIPAA §164.312. This makes your control mapping easier and your auditor’s review smoother.
Collect initial evidence. Firewall configuration exports. VPN access logs. Network segmentation diagrams. These prove the policy is implemented, not just documented.
Schedule the annual review before you close the file. Set a calendar reminder now. Set triggers too: architecture changes, incidents, and audit findings should prompt out-of-cycle reviews.
How to Enforce a Network Security Policy
A policy without enforcement is a wish list.
Technical enforcement is the most reliable. Use NAC (Network Access Control) systems to block non-compliant devices. Gate production access behind an MFA-protected VPN. Configure your SIEM to alert on out-of-policy events. If the control makes it technically difficult to violate the policy, you don’t need to rely on people remembering the rules.
Administrative enforcement covers the gaps technical controls can’t reach: policy acknowledgement on hire and annually, periodic training covering the rules most likely to be forgotten, and a clear disciplinary process for violations communicated upfront.
Audit enforcement is how you verify the gap between what the policy says and what’s actually happening. Quarterly or annual spot checks: do live firewall rules match the policy? Are vendor access credentials still valid? Are exceptions documented and within their approved expiry?
The gap between policy and reality is exactly what auditors look for. Close it systematically, not just on audit day.
Network Security Policy and Compliance: SOC 2, ISO 27001, HIPAA, and NIST
Every major compliance framework has specific things to say about network security. Most are more specific than people expect.
Your network security policy is the document that links your technical controls to your compliance posture. It’s not just supporting documentation; for several critical controls, it’s the primary evidence artefact.
| Framework | Relevant controls | What they require |
|---|---|---|
| SOC 2 | CC6.6, CC6.7 | Restrict logical access; prevent unauthorised external connections; protect data in transmission |
| ISO 27001 | 8.20, 8.21, 8.22 | Managed and controlled networks; documented service security requirements; network segmentation |
| HIPAA | §164.312 Technical Safeguards | Audit controls; person authentication; transmission security for ePHI |
| NIST CSF | PR.AC-3, PR.AC-5, PR.PT-4 | Managed remote access; network integrity protection; secure communications |
SOC 2 Network Security Policy Requirements
The AICPA’s Trust Services Criteria have two controls that directly require a network security policy:
CC6.6 requires that logical access to systems and data is restricted, and that the entity implements controls to prevent unauthorised access from external sources. Your network security policy is the document that formalises those restrictions.
CC6.7 requires that the entity restricts the transmission of sensitive data to authorised recipients and protects data in transit. Your policy’s clauses on approved protocols, VPN requirements, and prohibited transmission methods are what auditors check here.
What a SOC 2 auditor expects: an approved policy document, evidence that controls implement it (firewall configs, VPN logs, MFA enforcement records), and acknowledgements showing it was communicated to staff.
The most common gap: companies have working controls but no approved policy document that defines what those controls are supposed to do. CC6.6 and CC6.7 require both.
ISO 27001 Network Security Policy (Annex A 8.20–8.22)
ISO 27001:2022 dedicates three separate controls to network security, more specific than the 2013 version:
8.20 (Network security): Networks shall be managed and controlled to protect information in systems and applications. Your network security policy is the primary document satisfying this control.
8.21 (Security of network services): Security mechanisms, service levels, and management requirements for all network services shall be identified, implemented, and monitored. Your third-party access rules and service agreements with network providers support this control.
8.22 (Segregation of networks): Groups of information services, users, and systems shall be segregated on networks. Your segmentation table and the supporting network architecture diagram are the evidence.
HIPAA Network Security Policy
For any organisation handling electronic protected health information (ePHI), HIPAA Technical Safeguards (§164.312) require network-level controls to be documented, implemented, and maintained.
You must document: who can access the network containing ePHI, how access is logged and monitored, and how ePHI is protected in transmission (TLS minimum).
The most common HIPAA-specific gap I see: organisations focus on application-layer encryption and overlook network-layer access control documentation entirely. The HIPAA auditor asks for a network security policy and gets handed a firewall vendor’s datasheet. That’s not what they’re looking for.
NIST CSF Alignment
If you’re using NIST CSF as your control framework:
- PR.AC-3: Remote access is managed. Your VPN requirements and remote access rules address this directly.
- PR.AC-5: Network integrity is protected through segmentation. Your segmentation table addresses this.
- PR.PT-4: Communications and control networks are protected. Your firewall rules, monitoring configuration, and transmission security requirements cover this.
Free Template
Network Security Policy Template
Ready-to-use, audit-ready. Covers SOC 2, ISO 27001, HIPAA, and GDPR.
What Auditors Expect: Evidence and Records
I’ve been in SOC 2 reviews where the policy document was excellent: well-structured, specific, clearly approved. The evidence folder was empty. The auditor’s assessment: controls are present but untested. That’s not a pass.
Having the policy is the minimum. Auditors look for proof that it’s implemented, maintained, and actually followed.
| Record / proof type | What this looks like in practice |
|---|---|
| Approved policy document | Dated, version-controlled, signed or digitally approved by owner and exec |
| Policy acknowledgements | Signed by all employees and contractors with network access; dated; stored in HR or compliance system |
| Network architecture diagram | Current diagram showing segmentation: production, staging, corporate, guest, DMZ |
| Firewall rule documentation | Current ruleset export; change log with approvals for each rule change |
| VPN and remote access logs | Session logs; failed authentication attempts; unusual location or time flags |
| Network access control logs | Who accessed which segment and when; privilege escalation events |
| Monitoring and alerting configuration | SIEM rules active; alert thresholds configured; on-call escalation documented |
| Third-party access records | Vendor access approvals; time-limited credential logs; quarterly review sign-offs |
| Annual review record | Date of last review; changes made; approved by owner |
| Exception log | All approved exceptions; justification; expiry date; approver |
Common Mistakes That Create Audit Risk
These aren’t theoretical. They’re findings that come up repeatedly in pre-audit reviews and audit reports.
Watch out
A policy that exists but was never distributed is treated as non-existent by most auditors.
1. Writing the policy around your current setup, not your requirements. The policy should define what you need, not just document what you already have. If your current setup has a gap (say, no network segmentation between production and dev), the policy should call it out and set a remediation timeline. Not pretend the gap doesn’t exist. A policy that says “all good” when things aren’t is worse than no policy at all.
2. No network segmentation clause. Most auditors, across SOC 2 and ISO 27001, expect production to be isolated from dev and staging. If your policy doesn’t mention segmentation, you can’t enforce it or demonstrate it. Add the clause even if your current architecture doesn’t fully implement it yet, with a remediation date.
3. Treating guest Wi-Fi as low risk. Guest networks must be explicitly isolated from internal systems. Undocumented or un-isolated guest access is a recurring finding in SOC 2 Type II audits. The fix is simple: add a clause, verify the isolation is real, and document it.
4. Skipping third-party access rules. Vendors with network access and no documented approval process are a serious finding across SOC 2, ISO 27001, and HIPAA. “We gave the consultant VPN credentials” is not a controlled process. Add the approval workflow, the time limit, and the review cadence to your policy.
5. No formal exception process. Rules need a documented way to handle exceptions. The first time you open a port for a vendor without a formal approval on file is the first finding in your next audit. Build the exception process into the policy before you need it.
6. Policy not acknowledged by staff. A policy that exists but was never distributed is treated as non-existent by most auditors. Acknowledgement isn’t a formality; it’s the evidence that the policy was communicated. Don’t skip it.
7. Reviewing only after something breaks. Annual review is the minimum. Post-incident and post-architecture-change reviews are expected by ISO 27001 and NIST CSF. If your last review was triggered by a breach rather than a scheduled calendar date, that context matters to an auditor.
Right-Sizing by Company Stage
The right network security policy for a 12-person SaaS startup is not the right policy for a 300-person enterprise. Both need one, but what “done” looks like is different.
Quick tip
The policy you've had in place and reviewed for 12 months looks different from the one you wrote three weeks before the audit.
Startups (1–50 Employees)
At this stage, your network is mostly cloud: AWS or GCP VPCs, a VPN for remote access, Google Workspace for corporate tools, and maybe a small office with Wi-Fi.
Keep the policy practical. Cover the essentials: access controls, VPN requirements, approved devices, monitoring basics, and a named owner. One document, four to six pages. Don’t write for the company you might become; write for the company you are.
Priority: get it formally approved and acknowledged before your SOC 2 audit window opens. The policy you’ve had in place and reviewed for 12 months looks different from the one you wrote three weeks before the audit. Start early.
Growing Companies (50–200 Employees)
Your network is more complex now: multiple cloud environments, more third-party integrations, contractors in different geographies, and probably a small on-prem presence or office network.
Add: formal network segmentation rules between environments, a firewall change management process, a vendor access review cadence, and role-based access distinctions. Not everyone needs the same network access.
Start collecting evidence systematically: access logs, change records, acknowledgement exports, quarterly vendor reviews. Consider a dedicated security owner at this stage, rather than leaving network security with the founding CTO alongside seven other responsibilities.
Enterprise (200+ Employees)
Full network segmentation by function: production, corporate, guest, DMZ, partner access zones, and potentially separate segments for regulated data (PCI, HIPAA). A dedicated CISO or network security team owns the policy. The policy goes through a formal governance process with legal review and board visibility.
Sub-policies may make sense at this scale: a wireless security policy, a remote access policy, a vendor access policy, and a cloud security policy that branches from the main network security document. The master policy sets the principles; sub-policies define the specifics.
Network Security Policy Management with ComplyJet
Writing the policy is one afternoon. The harder part is everything that comes after: keeping it current, collecting acknowledgements, mapping it to framework controls, and building the evidence that shows auditors it’s actually implemented.
ComplyJet handles the full lifecycle. You start with a pre-built network security policy template, move through a structured approval workflow, and distribute it to staff directly from the platform. Employees acknowledge it digitally; the acknowledgement records are stored and exportable for audits.
The control mapping is built in: SOC 2 CC6.6 and CC6.7, ISO 27001 8.20 through 8.22, and HIPAA Technical Safeguards are all pre-mapped to your policy. When an auditor asks “what controls does this policy support?”, the answer is already documented.
Review reminders, exception tracking, and evidence collection are integrated. You’re not chasing people to sign PDFs or building spreadsheets to answer auditor requests.
Frequently Asked Questions (FAQ)
What is a network security policy, and what does it cover?
A network security policy is a formal document that defines how an organisation protects its networks, systems, and data from unauthorised access, misuse, and attack. It sets the rules for who can access the network, what devices are permitted, how remote access works, how network traffic is monitored, and how the network is segmented. It’s the governing document that sits above your technical controls (firewalls, VPNs, access control systems) and defines what those controls are supposed to enforce.
What is security policy in network security?
In the context of network security, a “security policy” refers to the documented set of rules governing how a network is protected, accessed, and monitored. The network security policy formalises those rules into an approved document that your team follows, auditors review, and your technical controls implement. Without the document, your controls exist but are ungovernable: there’s nothing to audit them against.
What is network security policy management?
Network security policy management is the ongoing process of creating, approving, distributing, enforcing, and updating a network security policy. It’s distinct from the one-time act of writing the policy. Management includes maintaining current acknowledgements from staff, tracking exceptions, mapping the policy to compliance controls, collecting evidence that it’s implemented, and reviewing the policy whenever your network architecture or compliance requirements change.
How do I implement a network security policy?
Start with a named owner, then audit your current architecture before writing anything. Customise the template in Section 6 to reflect your actual environment. Get formal approval from an exec or CISO. Communicate the policy to all staff and contractors with network access, collect signed acknowledgements, map each clause to your compliance framework controls, collect initial evidence (firewall configs, access logs, segmentation diagrams), and schedule the annual review. The 10-step rollout process in Section 7 covers each step in detail.
How do I enforce a network security policy?
Enforcement works across three layers. Technical: use NAC systems to block non-compliant devices, gate production behind an MFA-protected VPN, configure SIEM alerts for out-of-policy events. Administrative: collect acknowledgements, run periodic training, document the disciplinary process for violations. Audit: quarterly or annual checks that live controls match what the policy says, and that exceptions are documented and within their approved expiry dates.
Is a network security policy required for SOC 2?
Yes. SOC 2 Trust Services Criteria CC6.6 and CC6.7 explicitly require documented controls restricting logical access and protecting data in transmission. The network security policy is the primary document that satisfies these criteria. Auditors expect the policy document itself, evidence that the controls implement it, and acknowledgements showing it was communicated to staff.
Do I need a network security policy for HIPAA?
Yes. HIPAA Technical Safeguards (§164.312) require covered entities and business associates to implement documented controls governing network access to systems containing ePHI, including access controls, audit controls, person authentication, and transmission security. A HIPAA network security policy documenting those rules is expected by HIPAA auditors. Application-layer security alone is not sufficient.
How often should a network security policy be reviewed?
The minimum is annually. Beyond the calendar, review after: any material change to your network architecture or cloud environment, a network security incident or significant audit finding, a new compliance requirement affecting network security, or a major change in team size or structure. ISO 27001 and NIST CSF both expect evidence of trigger-based reviews, not just scheduled annual ones.
Related Security Policies
If you’re building out your security policy library, these policies connect directly to your network security policy:
Remote Access Policy: defines the rules for how employees and contractors connect to your network from outside the office. If the network security policy sets the overall framework for remote access, the remote access policy is where those rules get specific: which VPN, which tools, which protocols are approved.
Vulnerability Management Policy: covers how weaknesses in your network infrastructure and systems are identified, prioritised, and remediated. The network security policy defines the controls that should be in place; the vulnerability management policy defines how to find and fix gaps in those controls.
