UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 11.2 Free with a free account
Writing Network Security Policies and Guidelines
Ethics in Technology · Chapter 11: Secure Tunnels, Digital Rights, and Intellectual Property in a Connected WorldSection 11.2 · lesson 59 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Where the Right to Express Yourself Online Begins and Where It Ends →← Secure Encrypted Tunnels for Remote AccessNext lesson: Where the Right to Express Yourself Online Begins and Where It Ends →
In this lesson
Written commitments, practical rules, and governance frameworks.
- Distinguish policies, standards, procedures, and guidelines.
- Explain five common policy types and essential policy sections.
- Apply the policy lifecycle to personal-device and incident examples.
- Compare NIST CSF 2.0 with ISO/IEC 27001 management-system requirements.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,667 words). Read along, or search it.
Chapter 11
Network Security Policies
Security policies make leadership's protection expectations explicit and accountable. They state what must be protected and what people using the systems are expected to do. Standards define measurable requirements, while procedures explain how to perform a task. Guidelines provide advice rather than automatically imposing another mandatory rule. We apply these layers to company information on personally owned phones. Five common policies cover acceptable use, authentication, remote access, personal devices, and incident response. Current technical guidance matters when turning an intention into a password standard. Purpose, scope, responsibilities, enforcement, exceptions, definitions, and review ownership make policies usable. The lifecycle continues through communication, operation, monitoring, and reconsideration. NIST's six functions organize cybersecurity outcomes, while ISO requirements organize an information security management system. We connect written commitments with practical protection, personal privacy, fair treatment, and verified evidence.
Why Write the Rules?
Leadership Commitments Turn Intended Protection Into Accountable Expectations
A policy begins with a formal leadership commitment, rather than a technical product setting. It sets expectations about permitted, required, and forbidden activity. It assigns ownership for systems, decisions, tasks, maintenance, and resources. It helps staff and technical teams make consistent choices in similar situations. It explains how compliance is checked and consequences applied fairly. It can supply evidence of due care to relevant regulators, auditors, customers, or other interested parties. Documentation alone does not establish legal sufficiency or effective protection. Training, workable instructions, resources, and suitable controls must implement the commitment. Privacy and employee-owned equipment raise ethical questions about observation and authority. Accessibility and proportionality also affect whether legitimate users can comply. Communicate requirements clearly, apply them consistently, and provide accountable routes for justified exceptions instead of relying on a signature as proof of fairness.
Documentation Layers
Keep Stable Intent Separate From Requirements, Instructions, and Advice
A policy states high-level intent: what must be achieved, and why. The source example requires authenticated access to company systems. A standard specifies measurable requirements supporting that goal. The source's fourteen-character password and remote-MFA line illustrates this document type, rather than a universal current minimum. A procedure explains the actions needed when performing a task. Help desk identity verification before password reset is a practical example. A guideline offers recommended practice, such as considering a passphrase of several random words. It remains advice unless adopted into an applicable requirement. Separating these layers lets a changed technology update specifics without needlessly rewriting leadership's goal. Current digital identity requirements and device activation secrets have different contexts. High-level policies still need review when their intent or scope becomes outdated, rather than remaining untouched merely because they were designed to be stable.
From Policy to Practice
Translate Customer-Data Protection on Personal Phones Into Each Layer
The personal-phone example begins with protecting company and customer information. Its policy requires personally owned work devices to meet the relevant organizational protection standard. The standard requires a supported operating system and a separate managed work profile. It also gives a screen-lock example of at least six digits or appropriate biometrics. That device-lock example is not a universal rule for remote account passwords. The procedure explains enrollment through the approved management app. Sign in with the company account, accept the work profile, and confirm enrollment with the help desk. The guideline advises separating work and personal photos and avoiding untrusted app sources. Each document therefore has a different job, from intention to measurable requirement, action, or advice. Platform changes can require new standards or enrollment instructions while the protection goal remains valid. Explain and verify what management can actually observe, change, or erase, instead of assuming every platform supplies identical privacy boundaries.
Five Common Policies
Answer the User’s Practical Question and the Organization’s Operating Need
Acceptable use answers how people may use organizational technology. It covers permitted and forbidden activity, harassment, software installation, account sharing, monitoring notice, and consequences. Authentication policy answers how identities sign in and protect credentials. Remote-access policy defines approved protected methods, device conditions, multiple factors, and justified restrictions. A personal-device policy answers whether privately owned equipment may be used, and under what conditions. It covers enrollment, security settings, privacy boundaries, management, and lost equipment. Incident-response policy assigns reporting, escalation, communication, and action when something goes wrong. Employees, contractors, or relevant guests may acknowledge these conditions before access. Acknowledgment does not prove the user understood every requirement or could practically follow it. Use accessible explanations, realistic training, and suitable support. Implement privacy and fair enforcement openly, rather than hiding expansive surveillance in a click-through document and treating the click as complete justification.
Password Guidance
Update Technical Requirements Instead of Preserving Rituals
Technical standards should follow suitable current guidance instead of preserving old password rituals. The source's ninety-day rotation example describes a historical approach. Current NIST digital identity guidance does not require arbitrary periodic changes. It requires a change when evidence shows that the authenticator is compromised. Single-factor passwords require at least fifteen characters under this guidance. Passwords used only within multifactor authentication may be shorter, but must have at least eight characters. NIST does not impose mixtures of character classes as composition rules. Check proposed passwords against relevant common, expected, or compromised choices. Protect recovery, credential handling, and suitable MFA alongside password creation. Apply these digital identity requirements in context, rather than extending them to every device activation secret or claiming identical binding rules everywhere. Adopt standards meeting applicable obligations and assurance needs, with usable tools and accessible processes rather than a passphrase suggestion alone.
Fictional BYOD Excerpt
Make the Work-Profile Promise Concrete and Testable
The fictional BYOD excerpt allows employee and contractor personal-device work while protecting company information. Its requirements include enrollment, a screen lock, and current security updates. Its privacy promise limits management to the work profile. Personal apps, photos, messages, and browsing history are outside that promised scope. Loss or theft must be reported within twenty-four hours in this fictional example. Authorized management may erase the work profile. Policy failures can lead to lost access or proportionate disciplinary action. The Chief Information Security Officer owns the policy, with annual review. Those time periods are example commitments, rather than universal legal deadlines. Selective wiping and separation depend on platform, ownership mode, enrollment, and actual management permissions. Test the promised boundary, explain it clearly, provide support and suitable alternatives, and do not silently expose unrelated personal activity while claiming only work data is managed.
Incident Response and Policy Structure
Assign the Decision Before the Emergency
A usable policy identifies its purpose and scope before listing commands. It assigns roles, decision ownership, and resources. Clear policy statements specify what people must actually do. Compliance and enforcement sections explain checks and fair consequences. Exceptions need authorized approval, limited scope, justification, and review. Definitions create shared meaning, while an owner and review date assign maintenance responsibility. Incident policy also defines incidents, reporting, escalation, the response team, and authorized communication. Detailed plans and procedures support preparation, detection, analysis, containment, eradication, recovery, and learning. These remain useful activities even when frameworks organize them differently. NIST's April twenty twenty-five revision three integrates response into CSF risk management, so the older phase grouping is not the only current model. Outside notification depends on applicable obligations and facts; assign qualified decision owners instead of inventing a universal duty to notify every party after every event.
Policy Lifecycle
Communication and Review Keep the Written Rule Connected to Actual Work
The source's lifecycle has seven stages and feeds review back into identifying needs. Start by assessing risks, obligations, incidents, and organizational change. Draft with technical teams, HR, legal advisers, and affected users. Obtain leadership approval and assign ownership. Communicate through publication, training, explanation, and appropriate acknowledgment. Enforce through suitable controls and fair consequences. Monitor real operation, compliance, and approved exceptions. Review regularly and after relevant incidents or major change. Annual review is a planning example, while risk or applicable requirements can demand earlier reconsideration. Unreadable or undistributed documents do little for awareness, and obsolete instructions can undermine credibility. Use short explanations, practical support, and evidence of friction to correct the right document layer while maintaining leadership accountability for workable protection.
NIST CSF 2.0
Six Concurrent Functions Organize Outcomes, With Governance Across the Program
NIST first issued its Cybersecurity Framework in twenty fourteen for critical infrastructure. Version two point zero, released in February twenty twenty-four, extends its use across organization sizes and sectors. Its six functions organize outcomes and should operate concurrently. Govern establishes strategy, expectations, policy, roles, and oversight across the program. Identify addresses assets, context, risks, and improvement needs. Protect addresses safeguards that manage cybersecurity risk. Detect addresses finding and analyzing possible attacks or compromises. Respond addresses appropriate action concerning a detected incident. Recover addresses restoring affected operations and assets. The framework offers flexible guidance rather than one implementation recipe, and NIST does not issue formal CSF certification. Use it for gaps, priorities, and communication while still meeting any law, contract, or organizational obligation that requires particular adoption or outcomes.
ISO/IEC 27001
A Management System Combines Risk Decisions, Controls, and Continual Improvement
ISO and the International Electrotechnical Commission publish the information security management-system requirements standard. An ISMS combines organization-wide risk assessment, treatment, policies, responsibilities, and continual improvement. The source uses the twenty twenty-two edition, with applicable amendments also needing attention. ISO lists a twenty twenty-four amendment to that edition. Its reference controls number ninety-three, grouped into organizational, people, physical, and technological themes. Determine necessary controls through risk treatment and compare them with the reference set. Maintain justified applicability rather than treating every listed control as identical mandatory implementation for every organization. External certification bodies can assess conformity within the defined scope. ISO itself does not issue that certificate. Certification supports assurance without proving flawless security, universal maturity, or immunity from incidents. Examine scope, requirements, evidence, and ongoing operation, and distinguish implementing the system from optionally seeking certification unless an applicable obligation requires it.
Using the Frameworks Together
Plan Outcomes, Apply Requirements, and Verify Policy Behavior
The CSF and the ISO management-system standard can support the same security program in different ways. CSF outcomes help assess gaps, prioritize work, and communicate expectations. ISO requirements structure management, justified controls, improvement, and independent conformity assessment. CSF has no formal NIST certification, while independent ISO conformity certification is available. The source associates acceptable use with Govern and Protect. It associates passwords and remote access with Protect, and personal devices with Identify and Protect. Incident response connects Detect, Respond, and Recover. Those are illustrative connections rather than exclusive ownership; governance and implementation evidence cut across the program. The five review answers distinguish intent from steps, stable policy from changing specifics, and BYOD protection from personal privacy. They also explain why review preserves relevance and why outcome guidance differs from certifiable management requirements. Use suitable standards, procedures, and understandable advice together, verifying that practical protection and fair treatment match the organization's written commitments.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Writing Network Security Policies and Guidelines
What is the difference between a security policy, a standard, a procedure, and a guideline?
What are the current NIST password requirements?
What are the six functions of the NIST Cybersecurity Framework 2.0?
What is ISO/IEC 27001 and how does it differ from the NIST CSF?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →