What should I include in the request?

Include exact IP or CIDR in standard notation, numeric ports and protocol, a clear business justification, change window, rollback plan, and a contact for immediate follow-up to avoid delays.

How should IP ranges be formatted?

Use CIDR notation where applicable (for example 203.0.113.0/24) or precise start-end ranges. Avoid ambiguous descriptions and validate addresses before submission.

What qualifies as an emergency change?

An emergency change addresses an active outage or security incident. Follow the organization’s emergency change policy, obtain retrospective approvals, and document reasons and approvals in the ticket.

Can approvals be electronic?

Yes. Electronic approvals are valid under the ESIGN Act (15 U.S.C. ch. 96) and UETA where adopted provided intent, consent, attribution, and record retention requirements are met.

Who can revoke a whitelist entry?

The network owner or designated change authority can revoke entries; revocation should be logged, communicated to stakeholders, and, if reversible, include rollback steps.

How do I correct a submitted request?

Submit an updated request referencing the original ticket, mark the original as superseded, and require approvers to re-sign; do not implement changes from unapproved or corrected drafts.

Electronic Signature
Templates
Miscellaneous
IT Firewall Whitelisting

IT Firewall Whitelisting

This template is fully customizable. Edit the text, fill out the fields, and send it for signature. Give it a try!

IT FIREWALL WHITELISTING AGREEMENT

This IT Firewall Whitelisting Agreement ("Agreement") is entered into as of Effective Date: by and between Requesting Party: and Service Provider: .

WHEREAS

WHEREAS, Requesting Party operates systems and services that require network access through the Service Provider's firewall infrastructure, and requests specified outbound or inbound connections be permitted; and

WHEREAS, Service Provider maintains responsibility for firewall administration, security controls and change management and will implement whitelisting only in accordance with approved change control, testing, and rollback procedures; and

WHEREAS, the parties desire to define the scope, responsibilities, approvals, fees and legal terms governing the whitelisting request and its implementation.

SCOPE OF WORK

Description of Whitelisting Request

REQUEST DETAILS & TECHNICAL SPECIFICS

Requestor Name Department / Business Unit Business Owner Contact Email / Phone Source IP Address(es) / CIDR Destination IP / Hostname, Ports and Protocols Business Justification / Use Case

Requested Change Window Start: End: Expected Duration (hours):

Temporary or Permanent

Temporary Permanent

Rollback Plan / Reversion Steps Testing and Validation Procedure

APPROVALS & RISK ACKNOWLEDGEMENT

Security Review Completed: Yes No

Security Reviewer Name

Risk Level Identified: Mitigation Notes:

PAYMENT TERMS

Request processing, implementation, or advisory services provided by Service Provider shall be compensated as follows.

Total Fee Payment Schedule / Milestones

Late Payment Fee: A late fee of per month shall accrue on overdue amounts, calculated monthly.

TERM AND TERMINATION

This Agreement commences on Start Date: and, unless earlier terminated, continues until End Date: .

Termination Notice Period (days) Termination for Cause / Conditions

CONFIDENTIALITY

Each party acknowledges that during performance it may receive Confidential Information of the other party. "Confidential Information" includes technical details, IP addresses, configurations, security controls, business information and any non-public data disclosed in connection with this Agreement. The recipient shall:

(a) use Confidential Information solely to perform obligations under this Agreement; (b) protect such information with no less than reasonable care; and (c) not disclose Confidential Information to any third party except to those employees, contractors or agents who have a need to know and are bound by confidentiality obligations at least as protective as those herein. This obligation survives termination for a period of three years.

LIMITATION OF LIABILITY

Neither party shall be liable to the other for incidental, special, punitive or consequential damages arising out of or related to this Agreement, except for liability resulting from willful misconduct or gross negligence. Total liability for direct damages shall not exceed the total fees paid by Requesting Party for the particular whitelisting request.

GOVERNING LAW

This Agreement shall be governed by and construed in accordance with the laws of the jurisdiction specified below without regard to conflict of law principles.

Governing Jurisdiction

ENTIRE AGREEMENT

This Agreement, together with any exhibits and approved change requests documented and signed by authorized representatives of the parties, constitutes the entire agreement between the parties with respect to firewall whitelisting and supersedes all prior and contemporaneous agreements, representations, and understandings, whether written or oral.

COMPLIANCE CERTIFICATIONS

Requesting Party certifies that the requested whitelisting is necessary for legitimate business purposes, will not be used to evade security controls, and will comply with applicable laws and organizational policies. Requesting Party shall promptly notify Service Provider of any change in circumstances that renders this request invalid or poses additional risk.

Compliance Acknowledgement

Requesting Party acknowledges certification above

NOTICES

Primary Notice Contact for Requesting Party Primary Notice Contact for Service Provider

RECORDS & AUDIT

Service Provider shall maintain records of changes, approvals, and testing for a minimum of one year following implementation, and shall provide reasonable evidence of implementation upon written request consistent with confidentiality obligations.

Requesting Party:

By:

Date:

Service Provider:

By:

Date:

What an IT Firewall Whitelisting Request Is

An IT Firewall Whitelisting request is a formal record used to permit specific IP addresses, domain names, ports, protocols, or applications through an organization’s firewall for a defined purpose and period. The document captures requester details, technical parameters (CIDR blocks, ports, protocols), business justification, risk assessment, approval routing, scheduled change window, and rollback instructions. It is used by network and security teams to ensure changes follow change-control, reduce operational risk, and provide an auditable trail for compliance and incident response. Accurate fields and approvals help prevent unauthorized access and service disruption.

Why a Formal Whitelisting Request Matters

A documented whitelisting request preserves safety and accountability: it limits network exposure, ties changes to business need, enforces approvals, and creates an auditable record to support compliance and incident investigations.

Who Produces and Approves Whitelist Requests

Typical contributors include those who request access, technical owners who implement changes, and security teams who approve them.

IT and security administrators responsible for change control and firewall rule implementation.
Application owners or DevOps engineers requesting external access for services or integrations.
Compliance, risk, or network operations staff who review, approve, and audit changes.

Roles and signatory authority should be defined in the organization’s change-control policy to prevent ad hoc or unauthorized bypasses.

Core Sections of a Professional Whitelisting Request

A complete request organizes technical data, business justification, risk controls, approvers, scheduling, and verification steps so reviewers can quickly assess safety and impact.

Requester

Name, department, contact, and system owner. Identifies the accountable person and provides contact details for rapid follow-up during review or rollback.

Scope

Clearly specify IPs, domain names, ports, protocols, and target systems. Define whether access is inbound, outbound, or both and any CIDR notation used.

Technical Details

Provide source and destination addresses, port ranges, protocol (TCP/UDP), NAT details, and any session limits or rate controls to reduce exposure.

Risk Assessment

Summarize business impact, security risks, compensating controls (IDS, ACLs), and vulnerability scanning status to help approvers weigh trade-offs quickly.

Approval

List required approvers by role (network, security, compliance), approval order, and expected SLA to ensure timely implementation and accountability.

Verification

Post-change validation steps, monitoring instructions, rollback plan, and expiration date for temporary rules to avoid permanent exposure.

Step-by-Step: Submitting a Whitelist Request

Follow these stages to prepare, approve, and implement a safe firewall whitelist change.

01

Prepare Request: Collect CIDR, ports, business justification, and contact details.
02

Security Review: Submit to security for risk assessment and required compensating controls.
03

Approval Routing: Obtain signatures from network and compliance approvers per policy.
04

Implement and Verify: Apply rule in change window, test connectivity, and monitor for anomalies.

How to Configure an Electronic Approval Workflow

Define workflow settings so requests route automatically to the right approvers and record each action for audit purposes.

Field	Configuration
Authentication Method	SAML SSO or MFA for approvers
Approval Workflow	Sequential two-step network then security
Change Window	Pre-defined maintenance hours only
Notifications	Email alerts on status changes

Typical Request Routing and Implementation Flow

A clear flow reduces errors and ensures every change is authorized and validated.

Submit: Requester completes form and uploads evidence.
Review: Security verifies controls and approves or requests changes.
Apply: Network team schedules and applies firewall rule.
Validate: Post-change tests and monitoring confirm expected behavior.

Platform and File Requirements for Electronic Whitelist Requests

Use platforms that preserve field-level data, provide secure storage, and record an unalterable audit trail for each approval and signature.

File Types: PDF or DOCX for form templates
Integrations: Salesforce, NetSuite, Google Workspace
Authentication: SAML/SSO and MFA recommended

Choose tools that export signed PDFs and CSV logs, integrate with ticketing systems, and support conditional fields so approvers see only relevant data during review.

Export and Documentation Options

Keep signed records and exports that make audits and incident response straightforward.

Signed PDF

Export a tamper-evident PDF that includes timestamps, signer identity, and an audit trail suitable for archival and legal review.

CSV Log

Generate CSV exports of request metadata (requester, approvers, dates) for bulk reporting and configuration management databases.

System Ticket

Link each request to a change ticket (Jira, ServiceNow) so implementation steps and approvals are traceable.

Retention Export

Periodically export signed records for long-term retention and legal hold processing.

Critical Data Fields to Include

IP Address/CIDR: Exact CIDR or IP

Domain Name: FQDN

Ports/Protocol: Numeric ports and TCP/UDP

Change Window: Date/time range

Business Justification: Concise reason

Approver Signature: Signed approver name

Frequent Errors to Avoid

Submitting incomplete IP ranges or omitting CIDR notation, which forces clarification and delays implementation.
Using ambiguous port descriptions like 'open all ports' instead of specifying exact numeric ranges and protocols.
Skipping formal approval steps or using verbal approvals, which creates audit gaps and liability for unauthorized changes.
Leaving temporary rules without an expiration date, causing permanent exposure long after the justification expires.

Risks and Potential Consequences

Unauthorized Access: Increased breach risk

Compliance Violation: Regulatory exposure

Service Outage: Operational disruption

Audit Failure: Negative audit findings

Security Incident: Incident response costs

Financial Penalty: Fines or remediation costs

Typical Timelines and SLA Expectations

Establish clear SLAs so requesters and implementers share expectations and urgent changes are handled safely.

Standard Processing Time:

3–5 business days for routine requests

Emergency Change Window:

4 hours for pre-approved emergency incidents

Approval SLA:

Approvers respond within 48 hours

Implementation SLA:

Apply approved changes within 24 hours

Expiry and Review:

Temporary rules reviewed before end date

Milestones from Request to Verification

Track discrete milestones and required actions so progress is measurable and auditable.

01

Request Logged

Record ticket number and timestamp when submitted

02

Security Review

Assess risk and request mitigations if needed

03

Network Change

Apply rule during approved maintenance window

04

Post-Change Validation

Verify connectivity and monitor for anomalies

How Whitelist Requests Differ from Other Change Types

Compare common change request types so teams apply appropriate approvals and controls for each.

Criteria	Whitelist Request	Firewall Policy Change
Typical Scope	targeted ip/port	broad rule or policy
Approval Level	app and security	security and governance
Expiration	usually temporary	often permanent
Audit Detail	high granularity	policy-level logs

eSignature Vendor Pricing and Feature Snapshot

Common eSignature providers differ by pricing model and enterprise features; signNow is listed first for parity with other vendors.

	signNow	DocuSign	Adobe Sign	PandaDoc	HelloSign
Starting Price	$8/user/mo	$15/user/mo	$14/user/mo	$19/user/mo	$15/user/mo
Free Trial	7-day free trial	Varies by vendor	Varies by vendor	Varies by vendor	Varies by vendor
Bulk Send	Yes	Yes	Yes	Yes	No
Audit Trail	Yes	Yes	Yes	Yes	Yes
HIPAA Compliant	Yes	Yes	Yes	No	No
Envelope Cap	No cap	100 envelopes/user/year	Varies by plan	Varies by plan	Varies by plan

Real-World Examples of Digital Approval Workflows

Organizations reduce friction and preserve compliance by digitizing approvals; sample perspectives illustrate practical benefits.

Optica Ventures (COO)

A small operations team digitized approval forms to reduce turnaround time.

The interface simplified both internal use and customer interaction.
"The interface is simple and easy-to-use for our team; more importantly, it is just as easy for our customers."

Xerox (NetSuite Director)

An enterprise tied signature workflows to ERP and ticketing to automate change completion.

Integration removed manual handoffs and reconciliations.
"airSlate SignNow provides us with the flexibility needed to get the right signatures on the right documents, in the right formats, based on our integration with NetSuite."

Practical Tips for Accurate and Efficient Requests

Adopt consistent templates, validations, and SLA-driven routing to reduce rework and speed safe implementations.

Use Standardized Templates

Create a single template with required fields and format checks to prevent incomplete submissions; enforce CIDR validation and port numeric checks at form level to cut review time.

Limit Scope

Whitelist only the minimal address range and ports required. Narrow scopes reduce attacker surface area and simplify monitoring and rollback steps.

Set Expirations

Always include an automatic expiry for temporary rules and schedule a review pre-expiry to prevent forgotten permanent openings that create long-term risk.

Log and Monitor

Record change author, approvers, and timestamps in a tamper-evident log; enable monitoring and alerts for unusual traffic following a whitelist change.

Frequently Asked Questions and Troubleshooting

Answers to common questions about preparing, approving, and reversing firewall whitelisting changes.

Need help? Contact support

What should I include in the request?
Include exact IP or CIDR in standard notation, numeric ports and protocol, a clear business justification, change window, rollback plan, and a contact for immediate follow-up to avoid delays.
How should IP ranges be formatted?
Use CIDR notation where applicable (for example 203.0.113.0/24) or precise start-end ranges. Avoid ambiguous descriptions and validate addresses before submission.
What qualifies as an emergency change?
An emergency change addresses an active outage or security incident. Follow the organization’s emergency change policy, obtain retrospective approvals, and document reasons and approvals in the ticket.
Can approvals be electronic?
Yes. Electronic approvals are valid under the ESIGN Act (15 U.S.C. ch. 96) and UETA where adopted provided intent, consent, attribution, and record retention requirements are met.
Who can revoke a whitelist entry?
The network owner or designated change authority can revoke entries; revocation should be logged, communicated to stakeholders, and, if reversible, include rollback steps.
How do I correct a submitted request?
Submit an updated request referencing the original ticket, mark the original as superseded, and require approvers to re-sign; do not implement changes from unapproved or corrected drafts.

be ready to get more

Join over 28 million airSlate SignNow users

Sign Now