# Policies and Standards

**Policies and standards:** [**http://www.sans.org/security-resources/policies/**](http://www.sans.org/security-resources/policies/)

[**https://www.its.ny.gov/tables/technologypolicyindex.htm/security**](https://www.its.ny.gov/tables/technologypolicyindex.htm/security)

A **policy** is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an "Acceptable Use" policy would cover the rules and regulations for appropriate use of the computing facilities.

A **standard** is typically a collection of system-specific or procedural-specific requirements that must be met by everyone. For example, you might have a standard that describes how to harden a Windows 8.1 workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows 8.1 workstation on an external network segment. In addition, a standard can be a technology selection, e.g. Company Name uses Tenable SecurityCenter for continuous monitoring, and supporting policies and procedures define how it is used.

A **guideline** is typically a collection of system specific or procedural specific "suggestions" for best practice. They are not requirements to be met, but are strongly recommended. Effective security policies make frequent references to standards and guidelines that exist within an organization.

**List of basic policies required:**

1\. InfoSec Policy (main points for staff and also as required by regulators, clients etc.)

2\. Asset management (inventories and risk classifications for all assets, including people)

3\. Privilege management (approvals of access, AMP-like functionality, leavers/transfers) - all asset types (apps, infra, data repositories such as SharePoint sites etc.)

4\. Authentication (all use cases, including remote access), password complexity requirements etc.

4\. Vulnerability management (apps and infra, including patching SLAs)

5\. Resiliency (failover tests, recovery time objectives by risk classification etc.)

6\. Network segmentation (DMZ, allowed flows)

7\. Cryptography (allowed ciphers, mandatory use cases, crypto key management)

8\. Web access (blocking)

9\. Privacy (if it is in scope): masking, encrypting etc.

10\. BCP

11\. Physical security (data center and office access, environmental controls etc.)

12\. Media erasure and disposal

13\. Duty separation (no developer access to production, no business user access to code etc.)

14\. Application security (if in scope): input validation, output sanitizer ion, special controls for mobile apps.

15\. Backup/retention

16\. Basic infra security: hardened builds for operating systems, no access to removable media, control of elevated access (such as local admin), wireless controls.

17\. Forensics support (minimum logging, centralized log storage)

18\. Policy exception management.

19\. Incident management

20\. Adoption of third party product-specific security standards (e.g., Microsoft standard for MS Office - if such exists, BlackBerry etc.)

21\. Vendor management

22\. Training and awareness


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.swantu.com/policies-and-standards.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.