1. Roles and Responsibilities

Security is a shared responsibility that involves the entire organization. The following roles and their associated responsibilities are defined to implement and enforce this Information Security Policy. Each role is expected to carry out these duties in alignment with any corresponding obligations in our client or partner agreements:

1.1 Senior Management: 

Company leadership (CEO, Directors, and Department Heads) is ultimately accountable for information security. Senior Management shall demonstrate commitment to security by providing clear support for this policy, allocating necessary resources, and enforcing compliance across the organization. Management must also ensure that the Company meets any security-related contractual obligations. This includes: approving this policy and any updates; reviewing security reports and audit results; and supporting remediation efforts for identified issues. Management will foster a culture that prioritizes security and will lead by example in complying with all policies. They are responsible for appointing a qualified Information Security Officer and empowering that person to implement the security program and to intervene in business processes when needed to protect security. Senior Management will also ensure that appropriate insurance (e.g., cyber liability coverage) is maintained as required by contracts or law and that any certifications or compliance attestations (such as PCI DSS compliance, if applicable) are obtained and kept current.

Management Commitment: Our executive team acknowledges that robust security is both a business imperative and a contractual requirement. They regularly communicate the importance of security to all staff and evaluate management and team performance in part based on adherence to security procedures.

1.2 Information Security Officer (ISO):

The ISO (or equivalent security manager) is responsible for developing, implementing, and monitoring the information security program. The ISO will maintain this policy, update it as needed, and coordinate training and compliance efforts. Specific duties include conducting risk assessments, managing security audits (internal and external), overseeing incident response (Section 7), and serving as the point of contact for security matters. The ISO ensures that security controls meet legal and contractual requirements, and will map those requirements to specific practices. For example, if a client contract or regulation requires encryption of certain data or multi-factor authentication, the ISO will verify that the technical teams have implemented those controls. The ISO also reviews all new contracts, projects, or changes for security implications. If an agreement with a client or vendor imposes additional security obligations (e.g., background checks for staff, specific password rules, data residency requirements), the ISO will integrate those into our procedures and communicate them to relevant personnel. The ISO has authority to enforce compliance and to escalate security issues to Senior Management. The ISO will also coordinate any required security notifications to external parties (clients, regulators) in the event of an incident, as described in Section 7.2.

1.3 IT Department and System Owners:

The IT Department (including system administrators, network engineers, and application developers) is responsible for the secure configuration and maintenance of IT systems in accordance with this policy. They implement technical controls (access control, encryption, patch management, monitoring systems) and operational practices (backup, incident response drills) as defined here and in supporting procedures. System Owners (the primary managers or product owners for specific applications or data repositories) ensure those systems have appropriate security controls and that data is classified and handled properly. IT is also responsible for ensuring vendor-provided services are used securely and in line with any contracts. For example, if we use a cloud service under a contract that requires certain security configurations, IT must configure the service accordingly. IT personnel with privileged access must follow all rules for secure administration (Section 3) and are held to a high standard of confidentiality (privileged admins sign additional confidentiality agreements acknowledging the 5-year post-termination secrecy period on client data, etc.). The IT team also maintains documentation (network diagrams, asset inventories, backup logs) which may be required for audits or client requests. They support the ISO in risk assessments and provide information needed for security audits or client security questionnaires.

1.4 Employees and Contractors (All Users):

Every workforce member is responsible for protecting information in their possession and for following this policy. All users must:

• Adhere to Policies and Controls: Users shall comply with all security policies, standards, and procedures. This includes our Acceptable Use Policy, data handling procedures, and any client-specific security protocols that apply to their work. Users must also comply with the information security and confidentiality requirements of any client agreements relevant to their role. For example, if a project has a contract stating that only U.S. citizens may handle the data, the project lead must enforce that restriction. Or if a client’s policy (which we agreed to follow) requires no personal devices be used, users on that project must not use personal devices. It is the responsibility of managers to communicate any such client-imposed requirements to their teams, and every employee is responsible for honoring them.

• Protect Confidential Information: Users must keep confidential all sensitive information they handle as part of their job. Per our contracts, confidential information of clients and partners must be protected for at least 5 years after a contract ends (and longer for certain categories). Each employee and contractor signs a confidentiality agreement reflecting these obligations. Users should only share sensitive data with those who are authorized and have a need to know (see Section 4 on Data Handling). They must use approved secure channels for communication (e.g., our corporate email with encryption for external communications, or client-provided secure portals). Unauthorized sharing of confidential data – internally or externally – is strictly prohibited. If a user is unsure whether they can share information with someone (including within the Company), they should consult a supervisor or the ISO. Users must also report any suspected confidentiality breach immediately (Section 7.1).

• Use Company Systems Appropriately: Users shall use Company information systems and data strictly for legitimate business purposes. Activities that could jeopardize security or violate law/contract are forbidden. This includes: installing unapproved software, disabling security settings, using someone else’s credentials, or engaging in any illegal acts using our IT resources. All users must comply with our Acceptable Use Policy, which among other things prohibits using our systems to violate intellectual property rights (e.g., no pirated software) or to send spam or malicious content. Users are forbidden from attempting to bypass security controls; any such attempt can result in immediate disciplinary action. If a user feels a control is overly restrictive to their work, they should request a formal exception rather than circumventing it.

• Safeguard Authentication Methods: Users must keep their account credentials (passwords, tokens, key cards) confidential. They should never share passwords or MFA tokens, even with IT staff (IT will never ask for a password; they have privileged methods to assist without needing it). If a user suspects their password or account is compromised, they must change it immediately and inform IT. Users must follow the password guidelines in Section 3.5. Similarly, users must secure any physical keys or access badges; lost or stolen access cards must be reported at once so we can deactivate them. All employees are required to use multi-factor authentication (MFA) where it is implemented (VPN, email, etc.), as this is both a policy requirement and in some cases a contractual requirement for certain systems. They must not attempt to undermine MFA (like by approving unexpected login prompts – report those instead).

• Security Awareness: Users are expected to remain vigilant and informed about social engineering and other threats. Everyone must complete the Company’s security awareness training upon hire and annually. This training covers phishing risks, safe internet practices, and how to handle sensitive data. Users should be cautious with emails or messages – do not open attachments or click links from unknown or untrusted sources. If something seems phishy or too good to be true, verify it with IT Security. Our policy and many of our clients’ policies forbid ignoring potential phishing; when in doubt, check. We conduct periodic phishing simulation tests; users who repeatedly fail may receive additional training or other corrective action. The goal is to build a strong human firewall. Users are encouraged to report any suspicious emails or incidents (there will be no blame for reporting an honest mistake promptly – the emphasis is on quick containment).

• Incident Reporting and Cooperation: All employees and contractors must immediately report any suspected or actual security incidents (see Section 7.1 for examples and process) to the IT Security team. Quick reporting is essential not only for internal response but also because we may have external notification obligations (for instance, a client contract might require we notify them within 24 hours of a breach). If an incident involves client data or systems, employees are expected to fully cooperate with any investigation and response efforts, including preserving evidence, providing written statements, and working with client security teams or law enforcement if needed. No user shall impede an incident investigation – doing so could be a serious violation.

• Compliance with Regulatory and Contractual Requirements: Users involved in specialized data (e.g., personal health information, cardholder data, government client data) must follow all applicable regulations and specific contract requirements for that data. For instance, if handling PHI, users must comply with HIPAA Privacy and Security Rules as reflected in our internal HIPAA policies and any Business Associate Agreements. If working on a government contract that requires CJIS clearance, users must maintain that clearance and adhere to CJIS security policies as instructed. The Company will provide the necessary training and tools, but the user bears responsibility to apply them consistently.

In summary, every individual must act as a steward of the Company’s and our clients’ information. Security is part of everyone’s job description. Users who are uncertain about any aspect of this policy or a specific data handling situation should seek guidance from the ISO.

1.5 Third-Party Service Providers and Partners:

In some cases, external parties (consultants, vendors, contractors) may have access to our information or systems. All such third parties must be formally authorized and must sign the appropriate agreements (Non-Disclosure Agreement, Data Protection Agreement, etc.) before access is granted. The manager engaging a third party is responsible for ensuring that a confidentiality agreement is in place and that the third party understands our security requirements. Third parties with network or data access must abide by this Information Security Policy just as employees do. We will limit their access to only what they need (least privilege). Additionally, if a third party is providing a service to us that involves handling client data or personal data, our contract with them must include security and privacy requirements consistent with those we have to our clients. For example, if we outsource data shredding, the vendor contract must obligate them to shred to required standards and provide certificates of destruction (per our commitments to clients under T&C Section 6.6). Our ISO and Legal team will vet significant vendors for security adequacy (see Section 9 for Third-Party Security Management). Internally, any issues involving third parties (like a breach caused by a vendor) will be handled per our incident response plan, and we will enforce our contractual rights with the vendor (e.g. indemnification, assistance) as needed.

1.6 Conflict Resolution:

If any part of this policy appears to conflict with a specific legal or contractual obligation, the obligation will take precedence and this policy will be updated to reflect it. For instance, if a client contract stipulates a stricter standard than what’s in this policy (say, data must be encrypted using a specific algorithm), we will adhere to the stricter standard for that client’s data. The ISO should be informed of any such instances so we can adjust our general policy or apply a controlled exception.

By clearly defining these roles and responsibilities, we ensure that security accountability is assigned and understood at all levels. Everyone – from executives to new hires, and including external collaborators – has a duty to protect our information assets and those entrusted to us by our clients. This shared responsibility is critical to meeting our commitments and maintaining trust.

2. Information Asset Management and Classification

Effective protection of information begins with understanding what information we have and classifying it by sensitivity. The Company maintains an inventory of information assets and follows a classification scheme to ensure each asset receives appropriate security controls in line with its value, sensitivity, and applicable requirements (legal or contractual).

2.1 Asset Inventory:

The IT Department, under the guidance of the ISO, will maintain an up-to-date inventory of information assets. This includes hardware (servers, laptops, mobile devices), software applications, databases, network devices, and data repositories. For data assets, the inventory will identify the data owner (the person or team responsible), data location, and data classification. Asset inventory is important not only for internal control but also because many contracts require us to know where client data is stored and who has access. We tag assets that contain or process client confidential data or personal data so they can be given extra attention (e.g., in patching priorities, monitoring).

Each Department Head must ensure that information assets in their area (documents, spreadsheets, confidential plans, etc.) are known and accounted for. Shadow IT is discouraged; all business information should reside on approved systems where it can be inventoried and secured. We periodically audit the environment to discover untracked assets and incorporate them.

2.2 Data Classification:

All information is classified into one of four sensitivity levels – Public, Internal, Confidential, or Highly Confidential – as defined below. This classification determines the baseline security controls for handling that information (see Data Handling in Section 4.2). We classify data to ensure we are meeting both prudent security standards and specific client/regulatory requirements for certain data types.

• Public: Information intended for public release. Unauthorized disclosure of Public information would cause little or no harm. Examples: marketing brochures, job postings, published research, content on our public website. Public data can be shared freely, but still should be accurate and protected from unauthorized modification.

• Internal (Proprietary): Non-public business information that is not particularly sensitive. This is information we prefer to keep within the Company but whose exposure would not cause serious harm. Examples: routine internal emails, company policies, organization charts, project schedules, internal meeting notes. We restrict Internal data to employees and approved contractors. It requires a moderate level of control (e.g., accessible via login but not necessarily encrypted for storage). Many of our operational records fall here.

• Confidential: Sensitive information that, if disclosed or altered without authorization, could cause harm to the Company, clients, or individuals. This category includes most data that we have legal or contractual obligations to protect. Client data that we handle is typically Confidential by default (unless classified higher by contract). Examples: client project files and deliverables, client-provided business data, sales leads or customer lists, non-public financial records, employee personal information (home address, salary), passwords or keys (when stored), licensed software source code, etc. Also, any data a client designates as “Confidential” or similar in a contract must be treated at least as Confidential. Confidential data must be tightly controlled: access only on need-to-know basis, stored in secure locations, encrypted in transit, etc. According to our T&Cs, Confidential Information must be protected for 5 years after termination of a client engagement, so we must maintain confidentiality of such data even if our project is completed or an employee leaves. When in doubt, treat information as Confidential unless told otherwise by the data owner or ISO.

• Highly Confidential: Extremely sensitive information that warrants the highest level of protection. This includes data that could cause severe harm to the Company or our clients if compromised, or data we are required by law/contract to protect at a very high standard. Examples: trade secrets (formulas, algorithms), significant intellectual property under development, merger and acquisition plans, privileged legal documents, large aggregates of personal data (like an entire customer database), login credentials, cryptographic private keys, and any data specifically classified as Highly Confidential by a client or regulatory mandate. For instance, if we handle controlled unclassified information (CUI) for a government client, we treat it as Highly Confidential. Payment Card data (PANs) and personal health information (PHI) are typically Highly Confidential because of PCI DSS and HIPAA requirements. Trade secrets and certain personal data may also be subject to indefinite confidentiality per contract or law, so this class often implies ongoing obligations. Highly Confidential data should be accessed by only a small number of authorized individuals, stored and transmitted with strong encryption, and often kept off of less secure systems. Additional monitoring is applied (like alerts on any access).

Each information asset (document, database, etc.) should be assigned a classification by its owner or creator. When in doubt, err on classifying higher. If unclear, ask the ISO for guidance. It is easier to down-classify later than to clean up a breach of under-classified data.

We provide labels and markings for documents and files (e.g., templates have headers like “Confidential”) and encourage use of those markings, especially for Confidential and Highly Confidential information that is shared. Digital systems will be configured, where possible, to enforce classification (for example, our DLP system may tag or detect files with personal data and treat them as Confidential).

2.3 Handling Classified Data:

Section 4.2 of this policy details the required controls for each classification level (e.g., encryption requirements, sharing rules, destruction methods). In general, higher sensitivity means stricter controls. All employees must follow those rules once data is classified. Note that client data should be presumed Confidential or Highly Confidential unless the client explicitly states otherwise. Some contracts include specific handling instructions for client data categories – those will be followed in addition to our baseline controls. For instance, a contract might forbid copying certain data to portable drives; our policy then is not to do so, even if our general rules might allow it under strict encryption. The ISO maintains a list of any special client data handling requirements that override or augment our classification controls and will ensure responsible teams are aware.

2.4 Data Ownership:

Every information asset has an assigned “Data Owner” (usually a manager or department head) who is accountable for classifying that asset and determining who should have access. The Data Owner is also responsible for approving any external sharing of the data (e.g., sending to a client or partner) and for ultimately deciding when the data can be archived or destroyed (subject to retention requirements in Section 4.5). The concept of least privilege (Section 3) means Data Owners should approve access only to those who truly need it. If a question arises such as “Can we use this client data set for another purpose or share with another vendor?”, the Data Owner must consult contractual terms (often client data can only be used for defined purposes) and possibly seek client permission before approving. Data Owners work with IT to implement appropriate controls (for instance, if a Data Owner classifies a dataset as Highly Confidential, IT will ensure it’s stored in an encrypted repository with restricted permissions).

2.5 Review and Updates:

Data classification is reviewed at least annually or when there are changes. Sometimes information becomes less sensitive over time (e.g., a project deliverable might be Confidential during development but could become public upon client release). Conversely, new regulations can make some data more sensitive (for example, a list of emails might become more strictly protected under new privacy laws). Data Owners should periodically re-evaluate their information and confirm or adjust classifications. The ISO will include classification and access appropriateness as part of security audits. Additionally, any time we enter a new client contract, the onboarding process should identify any data that will be exchanged and ensure it’s classified and handled per contract requirements from the start.

Proper asset inventory and classification is critical for ensuring we apply the right level of protection consistently. By following this classification scheme, we also satisfy contractual obligations that require us to differentiate how we treat, say, confidential client information versus general information. All personnel must familiarize themselves with examples of each classification and refer to the Data Handling rules to know what safeguards to apply in each case.

3. Access Control

The Company implements strict access controls on systems and data to ensure that only authorized individuals can access information according to the principle of least privilege. Access control is central to preventing unauthorized use or disclosure of data and is also a common requirement in laws and contracts (for example, HIPAA requires unique user IDs and access management; many client contracts specify that we must restrict access to their data to those involved in their project).

This section outlines how accounts are managed, how access rights are granted, and the rules users must follow for secure authentication.

3.1 Account Provisioning and De-Provisioning:

• Unique User IDs: Every employee and contractor is assigned a unique user account for access to Company systems (and separate accounts for client systems if applicable). Shared accounts are not permitted except in very limited cases approved by the ISO (for instance, a shared service account for a system integration, which must still be carefully managed). Individual accountability is required by policy and by many frameworks – for example, PCI DSS and our own T&Cs mandate tracking of actions to a specific individual.

• Manager Authorization: Access to systems or data is granted based on role and approved by the user’s manager and the Data Owner (if specific data sets are involved). During onboarding, HR and IT use a checklist to grant standard access (email, intranet, etc.) and any job-specific access. The manager must confirm what Confidential/Highly Confidential data the new hire should access. No employee or contractor will be granted access to client confidential data or critical systems unless it’s necessary for their duties and approved by the responsible manager. For example, if an employee joins the marketing team, IT will not give access to engineering design files or client project folders unless specifically approved. This ensures need-to-know is enforced at provisioning.

• Secondary Approvals: Certain high-risk accesses require secondary approval by the ISO or senior management. For instance, adding someone to the Domain Administrators group or granting VPN access to a contractor may require ISO sign-off. Similarly, any access that is an exception to policy (e.g., a request to allow a contractor to remotely access a production database due to a special project) must be reviewed for contractual implications and approved by senior management in writing.

• Least Privilege Principle: Users are given the minimum privileges needed for their job functions. IT configures access based on predefined role profiles whenever possible (e.g., “Engineer”, “HR Generalist”, “Project Manager for Client X”). These profiles are aligned with our segregation of duties and lease privilege policies. If a user changes roles within the Company, their access shall be adjusted promptly – access no longer needed must be removed and new access added as necessary. It is against policy (and often against contract) for employees to accumulate privileges beyond what is needed. For example, if someone moves from Sales to Finance, they should no longer be able to see the sales CRM data but will need access to finance systems; IT will remove the CRM access and add finance access upon the role change.

• Account Deactivation: When an employee or contractor leaves the Company or no longer requires access, IT will disable their accounts immediately on their last day (or earlier, in case of involuntary termination). Managers and HR must notify IT in advance of departures whenever possible to plan timely de-provisioning. This includes accounts on internal systems and any external systems (client networks, cloud services) the person had. Rapid deactivation is crucial for security and is explicitly required in some client contracts (e.g., contracts often require us to revoke access of any person who no longer works on the project). We also periodically review login logs to ensure no “ghost” accounts remain active. For consultants or contractors with time-bound engagements, IT will set accounts to expire automatically at the contract end date (and extend only if formally renewed). Service accounts or generic accounts (if any exist) are changed or disabled when the responsible individual leaves or changes roles.

• Vendor and Client Accounts: If we have accounts to access a client’s systems, those accounts must only be used by the specific individuals authorized, and not shared. When those individuals leave or no longer need access, we will coordinate with the client to have those accounts disabled, as required by most MSAs. Conversely, if clients or vendors have accounts on our systems (e.g., a vendor performing support), we treat them like our own internal accounts regarding monitoring and disabling.

3.2 Authentication and Password Management:

• Strong Passwords: All user account passwords must meet our complexity requirements: at least 14 characters, including a mix of upper-case, lower-case, numeric, and special characters (unless a system imposes different but equivalent rules). Passwords must not contain easily guessable info (like the username or common words). These standards align with best practices and any requirements in client contracts for “strong passwords”. Passwords have a maximum lifetime of 90 days for standard users and 60 days for privileged administrators, after which they must be changed (some highly sensitive systems may enforce even more frequent changes). Users are discouraged from reusing passwords; our systems prevent reusing the last 5 passwords on major systems. If a system supports it, we encourage the use of passphrases (long passwords) for better security.

• Password Confidentiality: Users must never share their password or MFA token with anyone, including IT staff. IT will never ask for a user’s password; if IT needs access, they have separate admin methods. If a user needs a password reset, IT will verify identity through established procedures, then issue a temporary password which the user must change immediately upon first login.

• Multi-Factor Authentication (MFA): Wherever supported, the Company employs MFA to strengthen authentication. This is required for all remote access (VPN, Remote Desktop gateway, etc.), all administrative access, and all access to certain sensitive systems (e.g., cloud services containing client data). Many of our contracts stipulate MFA for access to client data or systems, and even when not explicitly required, we implement it as a prudent measure. Users must register at least two valid MFA methods (typically a mobile authenticator app and/or hardware token). Bypassing MFA or seeking to have a “MFA-exempt” account is not allowed unless an extraordinary situation arises and ISO approves a temporary exception (which is logged and subject to extra monitoring).

• Secure Credential Storage: All user passwords in Company systems are stored in a securely hashed form (never plaintext). IT ensures that system configuration uses strong hashing algorithms (e.g., bcrypt, PBKDF2) in line with compliance requirements (this satisfies contractual assurance that we follow industry standard security for authentication). Administrative passwords and service account credentials are stored in an encrypted password vault with very limited access.

• Account Lockout: To prevent brute-force attacks, systems are configured to lock out a user account after a certain number of failed login attempts (typically 5 tries within 15 minutes). Lockouts for user accounts last 15 minutes, after which the account unlocks, or an administrator can manually unlock after verifying with the user. This measure is especially required on externally facing services per best practices. Administrator accounts may be set to lock out indefinitely until IT intervention, as a further safeguard.

• Privileged Accounts: Users with privileged system accounts (like IT admins, database admins) will have two separate accounts: one regular user account for non-privileged use (email, web browsing) and one admin account used only for administrative tasks. The admin account will have a different password (and MFA) and is not to be used for routine activities to reduce risk. All privileged account use must be traceable to an individual admin (no shared admin logins). For certain highly sensitive administrative functions, we employ additional controls like “four-eyes” (two people required to authorize) if feasible, especially when required by compliance. Admins must also use secure administrative workstations or jump servers as provided (for instance, domain admins shall log in from a hardened admin VM, not from a general-purpose PC). These practices ensure compliance with contractual obligations to use “appropriate controls for privileged access” and protect client systems when our admins have access.

• Two-Person Integrity: Tasks involving highly sensitive changes (e.g., changing system security settings, granting someone access to a Highly Confidential data repository, or deploying to production systems that host client data) may require two-person authorization in some cases. When a contract or regulation calls for segregation of duties, we implement it. For example, the person who develops code cannot be the sole approver to push it to production if that system holds client financial data, to meet SOX or similar requirements.

3.3 Access Reviews:

• Regular User Access Reviews: Department heads and data owners, in coordination with IT and the ISO, will conduct access rights reviews at least quarterly for critical systems and bi-annually for all systems. These reviews involve checking current user accounts and their permissions against what is needed. Any excess or outdated privileges are revoked. For instance, the finance manager will review who has access to financial folders and remove anyone who no longer needs it (perhaps someone who moved to a different department). The ISO may schedule more frequent reviews for systems containing client confidential information, as contractually we may need to attest that only authorized project team members can access client data. We document these reviews and retain the records for audit or client compliance verification.

• Contract-Specific Audits: If required by certain client agreements, we will provide the client with a list of our users who have access to their data, either periodically or upon request. Our classification and inventory efforts in Section 2 support this. We then promptly correct any access that the client objects to (for example, if a client asks us to remove a specific person from their project data access due to a conflict, we will do so immediately as long as it doesn’t breach other obligations).

• Dormant Accounts: IT monitors for inactive accounts. User accounts that have not been used in 45 days or more are disabled unless a valid reason is known (such as extended leave). This helps prevent forgotten accounts from being compromised. Service accounts or vendor accounts that haven’t been used in a while are also candidates for disabling, in line with least privilege.

• Privileged Access Monitoring: The ISO and IT Security will continuously monitor the use of privileged accounts (via logs and alerts). We perform a monthly review of all admin group memberships and high-level privileges to ensure they remain appropriate. Because many breaches involve misuse of admin credentials, this is a focus area. Any anomalies (e.g., an admin account that hasn’t been used in months) are investigated and possibly removed.

3.4 Remote and Third-Party Access Controls:

• Remote Access: All remote access to Company networks (from outside our physical offices) must go through secure methods managed by IT, typically our VPN with MFA or a secure virtual desktop solution. Direct remote desktop or direct database connections from the internet are not allowed. The VPN enforces user authentication and MFA, and restricts users to network resources per their authorization. For example, when a user connects via VPN, internal firewall rules permit them only the same access they’d have on-site (no blanket network access). Remote access may be logged in more detail to meet certain client security addenda (some clients require logging of any remote access to their systems/data). All provisions of this policy apply equally when working remotely – users must ensure they work in a private space and that their family or others cannot eavesdrop on confidential work.

• Third-Party (Vendor) Access: If we grant network or system access to a third-party (e.g., an MSP technician or a software vendor for support), that third party will be given their own credentials and must use MFA if possible. Their access will be time-bound and scoped to the minimum necessary. For example, we enable a vendor account only for the duration of the support session and disable it afterward, per MSA allowances for emergency out-of-scope work. We also typically supervise third-party remote sessions (someone in IT may watch what the vendor is doing, or the session is recorded). Our vendor agreements include clauses that the vendor will comply with our security requirements, and our internal procedures treat third-party logins same as internal for monitoring and review.

• Client-Managed Systems: In cases where our employees access client systems (like logging into a client’s network), they must also abide by the client’s access policies. If a client requires using client-issued accounts or VPN, our staff will follow those rules strictly. Any client data accessed through those means must still be protected on our side according to our policy (e.g., not downloading it onto an unencrypted device). Essentially, when working within client environments, abide by both our policy and any stricter client policies. Report to our ISO if you encounter a conflict.

• Segregation of Client Data: Access controls are configured to segregate different clients’ data. If we host data from multiple clients on our systems, we use logical separation so that users only working on Client A cannot see Client B’s data. This is often a contractual requirement for us as a service provider (to prevent cross-client data leakage). For collaboration platforms, we use separate project workspaces or permissions per client project.

3.5 Access Control Enforcement and Exceptions:

• Access Enforcement: Our systems enforce access rules through directory permissions, ACLs, RBAC, etc., administered by IT. Users should not attempt to bypass these (such as “shoulder-surfing” someone else’s logged in session or using tools to elevate privileges). Suspected unauthorized access is an incident and must be reported.

• Temporary Access & Emergency Elevation: Occasionally, a user may need elevated access temporarily (e.g., a developer needs admin rights on a server for one day to deploy a patch). Such access can be granted on a time-limited basis with proper approvals and must be removed immediately after the need ends. All such exceptions are logged. In emergencies (e.g., an incident at 2 AM requiring quick access changes), IT may grant necessary access to address the issue but will document it and ensure it’s revoked post-incident. These practices guarantee that even unusual access is tracked and reined in, aligning with contractual promises to maintain least privilege except where absolutely needed in an emergency.

• User Responsibilities: Users must use only their own credentials. Using someone else’s account or sharing login sessions is forbidden. Users are responsible for activity done under their accounts. If you suspect someone else knows your password, change it and notify IT – do not risk unauthorized use. Also, lock your workstation when stepping away to prevent misuse by passersby (this is part of physical security but ties into access control). On mobile devices, use device passwords and follow our mobile device policy (which enforces screen locks, etc., for devices that access company email or data).

• Dual-Factor on Sensitive Systems: In certain especially sensitive contexts (like accessing production servers with client data or financial systems), we enforce two-person approval or out-of-band confirmation for critical actions. For example, initiating a large fund transfer might require a second confirmation by a supervisor – this is more an operational control but is noted here as it overlaps with access management (ensuring not one person can unilaterally misuse access to cause major damage).

• Audit and Accountability: System and data access are logged (see Section 5.4). Users should be aware their access activities (file openings, admin commands) may be monitored to detect inappropriate use. This logging also helps us fulfill obligations to account for data access (some clients require an audit trail of who accessed their confidential information). We have the capability to produce such logs if needed for investigations or client inquiries.

• Exceptions: Any requested exception to the access control policies (e.g., a user claims they cannot perform their job under these restrictions) must be reviewed by the ISO. If an exception is granted, it will typically be for a limited time and with compensating controls. For instance, if an automated system account needs to run without MFA, we might isolate that account’s permissions and monitor its usage closely as a trade-off. Exceptions will be documented and, if applicable, client approval will be obtained when a client’s data is involved (for example, if a client’s policy said “no subcontractor access without permission” and we needed to give a subcontractor access, we’d ask the client first).

Access control is one of the most critical aspects of security. By adhering to these access management processes, we reduce the risk of unauthorized data access (which is central to maintaining confidentiality commitments) and demonstrate due diligence in safeguarding systems (which we may need to prove in audits or in the event of an incident investigation). Always remember: access is a privilege – and one tied tightly to trust and verification.

4. Data Protection and Privacy

This section details how we protect data throughout its lifecycle – from creation and storage to transfer and disposal – according to its classification (Section 2.2) and any legal/contractual requirements. We also address how we comply with data protection laws and privacy obligations, which is critical given the nature of personal data we handle and the commitments we’ve made (e.g., in contracts and privacy notices).

4.1 Data Handling Requirements by Classification:

The following controls apply based on the classification of information (as determined in Section 2):

• Public Data: May be stored and transmitted without encryption, and can be posted on public websites. Integrity should still be protected – use source control for website content and require authorization for changes to prevent defacement. No special handling required at disposal (ordinary deletion is fine). Example: a press release can be emailed without encryption and thrown away in regular trash after use.

• Internal Data: Should be accessed only by employees/contractors. It can reside on our internal network without mandatory encryption, though many internal systems do encrypt data at rest by default. When sending Internal data via email externally, consider if it should be marked “Company Proprietary – For internal use only” to signal the receiver. If an internal document (like a company policy) is to be shared outside, ensure no Confidential info is embedded. Dispose of Internal documents by shredding or deleting – not required by contract, but good practice. Essentially, keep it within the company or trusted parties.

• Confidential Data: Must be protected in transit and at rest. All Confidential data stored electronically must be on secured servers or with strong encryption if on portable media or cloud. For example, files containing client confidential info or PII should be stored on an encrypted drive or in a SharePoint site with limited access. We use encryption technologies (AES-256, TLS 1.2+) to protect Confidential data:

• At Rest: Servers and databases housing Confidential data should use full-disk or file-level encryption whenever feasible (we have enabled BitLocker on all company laptops and file server drives, per best practice and to meet many contracts’ requirement to encrypt sensitive data storage). Cloud storage of Confidential data must leverage encryption provided by the cloud (and we manage keys or rely on provider’s certified encryption).

• In Transit: Confidential data must be sent using encrypted channels – e.g. HTTPS web connections, SFTP or SSL-secured email. Standard email within our Microsoft 365 tenant is TLS-secured by default. If emailing Confidential data outside our organization, users should apply our email encryption feature or send via a secure link (SharePoint/OneDrive link with access controls) rather than as plaintext attachment. We have a Data Loss Prevention (DLP) system that will warn or block if someone tries to send obvious Confidential data (like a list of SSNs) unencrypted.

• Need-to-Know Access: Only those with a legitimate need should access Confidential info (reinforcing Section 3). For client data labeled Confidential, limit access to the project team and supporting IT staff – no one else. For personal data of employees (HR records), limit to HR and a few executives.

• Physical Copies: If Confidential information is printed or in writing, it must not be left unattended in public areas. Store in locked drawers or rooms. Use cover sheets marked “Confidential.” When no longer needed, shred paper containing Confidential data using cross-cut shredders or a professional shredding service. Under our T&Cs, upon request or termination of a contract, we must return or destroy a client’s Confidential Information and confirm it, so our disposal procedures ensure no stray confidential client docs linger. Logs of destruction can be provided if needed.

• Backup and Recovery: Confidential data is included in our backups, but backup media (where used) are encrypted and secured. Offsite backups in cloud are encrypted. Access to backups is restricted similar to production. We retain Confidential data only as long as necessary (see Retention below) and will purge it from backups as feasible when no longer needed (except archival copy as allowed).

• Highly Confidential Data: Must be encrypted at rest and in transit without exception. Additionally, it often requires extra access restrictions and monitoring:

• Storage: Highly Confidential files/data must reside in encrypted form even on servers (e.g., in an encrypted database column or using a tool like Microsoft Azure Information Protection for file-level encryption). If only a portion of a system’s data is Highly Confidential, that portion should be isolated or separately encrypted. For instance, we encrypt database fields storing credit card numbers (on top of whole DB encryption) as a compensating control required by PCI.

• Transport: Use strongest encryption protocols (TLS 1.3 if available, or a VPN for transferring data). Many Highly Confidential datasets (like large citizen data sets for a government client) should only be transferred via secure dedicated means – not over the general internet if possible. If we must ship data on physical media (rare), it must be encrypted and shipped via secure courier with tracking, per any contract instructions.

• Access Control: Multi-factor authentication is mandatory for user accounts that access Highly Confidential data remotely. Moreover, consider split knowledge or two-person rule if applicable (as mentioned, certain actions requiring two people). All access to Highly Confidential data is logged in detail and reviewed regularly (e.g., daily log review of admin access to a PHI database). If a client requires it, we can provide an access log or report for their Highly Confidential data to prove compliance.

• Personnel: Where needed, personnel handling Highly Confidential info may undergo additional screening (like background checks) in line with contractual obligations. For example, if required by DOJ policy for CJIS data, employees accessing it will have fingerprint checks. If a contract restricts certain data access to citizens of a certain country, we enforce that in hiring/assignment.

• Physical Security: Store physical media or printouts of Highly Confidential info in safes or similarly secure containers. Limit copies. If working on such data in the office, use private rooms to prevent eavesdropping.

• Destruction: When disposing of Highly Confidential data, use secure methods like cross-cut shredding for paper, and for electronic data, perform secure erasure (multiple overwrite or degaussing) or physical destruction of drives. Merely deleting or recycling is insufficient. For example, when retiring a server that contained patient data, we will wipe its drives to DoD standards or shred the drives, and maintain a record of that action (which we can furnish if audited).

• Given the critical nature, the ISO may implement continuous DLP monitoring on Highly Confidential data flows (like alerts if such data is emailed or moved to an unapproved location).

• Legal/Contractual specifics: If a client contract or law (like GDPR) dictates special measures (like pseudonymization of personal data or data localization), we implement those for that data set too. Highly Confidential often includes regulated data, so compliance with those regulations (HIPAA, PCI, etc.) is integrated here.

4.2 Data Privacy Compliance:

We handle personal data of various types (employee data, customer data for clients, etc.) and are committed to protecting it in accordance with privacy laws (GDPR, CCPA, etc.) and our contractual privacy commitments. Key privacy principles we follow:

• Limitation on Use and Disclosure: We collect and use personal information only for legitimate business purposes and as consented to by the individual or permitted by law. For client-supplied personal data, we use it only for the purposes defined in our agreement (for example, if a client gives us a list of their customers to conduct a survey, we will not use that list for any other purpose or our own marketing without permission). This aligns with the typical contract clause that we act as a data processor only under the client’s instructions. We will not disclose personal data to third parties unless authorized (via contract or legal requirement). If a law or subpoena compels us to disclose client personal data, we will notify the client promptly unless prohibited (fulfilling typical contract terms).

• Data Minimization: We strive to limit personal data collected to what is necessary. If we can avoid storing certain sensitive personal details, we will (e.g. not storing full credit card numbers when not needed). This reduces risk and helps comply with regulations that require data minimization.

• Transparency and Consent: We maintain privacy notices for employees and any individuals whose data we hold. For client data, the client is responsible for obtaining their customers’ consent as needed, but we support them by handling data as agreed. Internally, our HR informs employees about what data is collected and how it’s used. If we ever need to use personal data for a new purpose, we will seek consent or ensure it’s allowed by law.

• Individual Rights: The Company honors applicable individual rights regarding personal data (access, correction, deletion, etc.). For example, if an employee requests to see their personal file or a customer of a client asks us (via the client) to delete their data under GDPR, we will cooperate fully. Our contracts as a data processor often require us to assist clients in fulfilling such data subject requests, so we have procedures to search, retrieve, and remove data on request within required timelines (usually 30 days). Any such requests received are forwarded to the ISO and Privacy Officer for handling.

• Data Export Restriction: Some data (like Personal Data under GDPR or certain government data) must remain in certain jurisdictions. We will abide by all data transfer restrictions stated in contracts. For instance, if a client’s data cannot leave the EU, we will only host and process it on EU-based systems. If we are not equipped to guarantee that, we will disclose it to the client and not accept the data. Similarly, if working with government sensitive data, ensure it’s not stored on systems accessible by foreign nationals if prohibited.

• Privacy by Design: When designing new processes or systems, we incorporate privacy considerations (like defaulting to mask personal info where not needed, segregating personal data from other data, etc.). The ISO/Privacy Officer reviews new initiatives to ensure compliance from the start. This helps meet legal requirements (GDPR’s privacy by design) and contract expectations that we will maintain a robust data protection program.

• Breach Response for Personal Data: In the event of a data breach involving personal data, we follow Section 7 for incident response but specifically ensure to meet any privacy law obligations. That typically means assessing the scope of personal data involved and notifying the appropriate parties. If it’s client personal data, we notify the client without delay (contractually often “immediately” or within 24 hours) so they can notify regulators or individuals as needed. We stand ready to provide details for the client’s regulatory notifications (e.g., nature of data, affected individuals count, mitigation steps). If it’s our own employee data, and a reportable breach under a law like state breach notification laws, we (the Company) will handle individual and regulator notifications within the required timelines. Our incident response plan covers these communications (see 7.2).

• Confidentiality Agreements: Every employee and contractor with access to personal data is bound by confidentiality agreements (as noted in Section 1.4) that cover personal data. These agreements typically have no expiration for sensitive personal data (consistent with our T&Cs which treat personal data as indefinite confidentiality).

• Vendor Management for Personal Data: If we share personal data with a third-party service provider (like a payroll processor or cloud provider), we will have a Data Processing Agreement (DPA) or equivalent in place requiring them to protect the data to our standards. We flow down any relevant privacy obligations (e.g., if a client contract says no data can be subcontracted without consent, we will not allow our subprocessors to further subcontract without client consent). We also limit what personal data vendors receive to the minimum needed (for example, giving a marketing firm anonymized data if identifiable info isn’t necessary).

By following these data protection practices, we not only guard against breaches but also fulfill our contractual promises (most client contracts have sections requiring us to handle their data with care, comply with laws like GDPR, notify them of breaches, and assist with compliance). All employees must treat personal data with the same care as Confidential data (at a minimum) and usually as Highly Confidential if it’s sensitive (financial info, health info).

4.3 Data Retention and Deletion:

We retain business and personal data only as long as needed for business or to meet legal/contractual obligations, and then we securely delete it.

• Retention Schedules: The Company maintains a data retention schedule in line with legal requirements and business needs. For instance, financial records are kept 7 years for IRS compliance, job applicant records maybe 1 year for EEOC, emails for a certain period unless litigation hold, etc. Client data retention is often defined by our contract – e.g., some MSAs say upon termination we must return or delete client data except for required archives. Absent a specific provision, we default to deleting client project data within 90 days after project completion (after confirming the client has what they need). If a client requests a different retention period, we accommodate it contractually and implement it.

• Contractual Deletion Requests: As per our General T&Cs and many MSAs, if a client requests the return or destruction of their data, we shall comply promptly and certify completion. Upon such request, the IT and ISO will identify all locations of that client’s data (primary systems, backups, etc.), ensure it’s removed, and provide a confirmation letter. We keep a copy of any data destruction certificate internally and (if allowed) an archival copy of data for legal record as permitted by contract – but that archival copy remains protected and eventually destroyed per our retention policy.

• Legal Holds: If we are aware of any litigation or investigation that requires data preservation, we suspend deletion of relevant data even if its retention period is elapsed. This override is coordinated by legal counsel and ISO (and often communicated to us by clients or courts). For instance, if a client is in litigation and asks us to preserve related communications, we put those mailboxes on hold. Once the hold is released, we resume normal deletion schedules.

• Disposal Methods: When data is due for deletion:

• Electronic data is securely erased. For cloud systems, we delete using the provider’s secure deletion function (which typically makes the data inaccessible and eventually overwritten). For files on servers, simple deletion may leave traces; thus for Highly Confidential data we use file shredding tools or encrypt then delete keys to make it unrecoverable. For whole disk disposal, see Hardware disposal below.

• Physical documents are shredded using cross-cut shredders or placed in locked shred bins for our shredding vendor to destroy. We keep vendor certificates of destruction on file to prove compliance (some clients, especially regulated ones, may audit our disposal records as part of vendor oversight).

• Backup tapes/hard drives: If a backup contained data now beyond retention, we preferentially delete that data from backups where possible. If not possible (some backups are immutable), we ensure those backups are encrypted and eventually destroyed at media end-of-life. Old backup tapes are degaussed or physically destroyed. Hard drives are wiped or crushed before disposal.

• End-of-life hardware: Any equipment leaving our control (e.g., old laptops returned from employees, leased gear, or faulty drives) is sanitized. Laptops are re-imaged (which wipes prior data) before reissue or resale; if going out of company, we fully wipe or remove the drive. Failed drives under warranty are either destroyed or sent back to vendor in encrypted state (or under an assurance they destroy it). We log serial numbers of drives destroyed to document that no data left on them.

• Personal Data Deletion: In compliance with privacy laws and client DPAs, if an individual (user, customer, etc.) exercises the right to erasure, and no lawful exception applies, we delete their personal data from our systems. If that data resides in client systems we manage, we’ll assist the client in deletion. We make sure to also delete it from all live systems we control and request its deletion from any subprocessors (like asking our cloud SaaS to remove a user’s data). If law prohibits full deletion (e.g., payroll records we must keep for taxes), we inform the individual of that and secure the data until we can delete.

Adhering to strict retention and secure deletion practices helps minimize our data footprint and thus risk. It also directly fulfills commitments such as “return or destroy upon termination” clauses and obligations under privacy laws to not keep personal data longer than necessary. All employees should periodically clean out data they control according to policies (with Data Owner guidance) – for instance, don’t keep old confidential reports indefinitely “just in case,” if we have no obligation or need, they should be archived or deleted. The ISO will periodically remind teams of data retention rules.

4.4 Data Transfer and Sharing:

Whenever we transfer sensitive data, either internally or to external parties, we must use secure methods and adhere to any third-party data-sharing agreements.

• Internal Transfers: Within our network, use approved shared drives or collaboration sites for sharing Confidential info, instead of emailing files around, to maintain centralized control. Ensure permissions on those shared resources are correct (IT can assist, as per Section 3). Do not copy confidential files to unsecured locations (like an open network share everyone can see). If you need to give someone new access to a folder, go through proper approval as Section 3 describes.

• Email and Messaging: As mentioned, use encryption for external emails containing Confidential or Highly Confidential data (our email client has a “Encrypt” option which sends the message via a secure portal). Avoid sending passwords via email; share secrets through our password manager or verbally if absolutely needed (never in the same channel as related info). For Highly Confidential or large datasets, don’t use email at all – use secure file transfer. We have a secure file transfer appliance for very large or sensitive data exchanges. No sensitive data should be sent via consumer IM or SMS. Company-approved tools (Teams with external guest access, for example) can be used for business communications with appropriate caution (Teams chats are encrypted in transit but not intended for sharing things like credit card numbers – our DLP monitors chat content too). If a client or partner provides a secure portal, staff should use that rather than less secure means.

• Third-Party Sharing: Before sending any Confidential data to a third-party (client, vendor, etc.), ensure an NDA or appropriate clause is in place. If a client has already obligated us via contract to keep info confidential, that suffices for sending it to them. But if we are sending our confidential info to a vendor, confirm we have an NDA from them. Always use secure channels (SFTP, encrypted email, etc.). If we share data with a vendor for processing, ensure our DPA or contract covers what they can do with it and that they will either return or delete it when done. Maintain a record of what was shared, when, and to whom (at least informally via email record), in case we later need to verify what happened to it or confirm deletion.

• Client Data to Client: When returning data to a client (end of project or upon their request), do so securely. For instance, instead of emailing a database, put it on an encrypted USB drive and deliver via tracked courier, or upload to the client’s secure server. Then delete our copy unless legally required to keep (as discussed). Get acknowledgment from the client that they received everything needed and we can proceed to remove our copies.

• Media and Devices: Use only Company-approved and encrypted USB drives for any sensitive data transport. Personal flash drives should never be used for Company or client confidential info. If an employee must travel with sensitive data, they should have it on an encrypted laptop or encrypted drive, and carry it on-person (not in checked luggage, etc.), as per Section 6 (Physical Security).

• Encryption Management: The ISO/IT manages encryption keys. For any user-level encryption (like if using 7-Zip with a password to encrypt a file for transfer), the password must be sent via a separate channel (e.g., text or phone) not in the same email. Ideally use formal PKI or our secure file portal to avoid that issue. Under contract, we sometimes might need to use client-provided encryption tools or keys; we will accommodate that (for example, client gives us PGP key to encrypt files we send to them – employees handling that will be trained to use that key for all transfers to that client).

Following these data transfer guidelines keeps us compliant with statements in contracts that “Contractor shall use secure means to transmit client’s data” and prevents accidental leaks (which have been a common breach scenario in industry). When in doubt about how to send or share data securely, consult IT.

4.5 Monitoring and Logging of Data Access:

As part of protecting data, we log access and use of sensitive information to detect unauthorized activity and to prove compliance:

• Access Logs: Systems that store Confidential or Highly Confidential data are configured to log user access events (logins, file access, data queries). For example, our document management logs who opened or downloaded a confidential report, and our database logs administrative actions on tables with personal data. These logs are kept at least 1 year or as required by contracts (some contracts might require availability of logs for 2+ years for audit).

• DLP Monitoring: We use Data Loss Prevention tools that monitor network traffic, emails, and endpoint activities for patterns that indicate potential unauthorized data egress (like a user uploading a bunch of confidential files to a personal cloud account). When triggered, these generate alerts to IT Security. By policy, employees should not try to circumvent DLP (e.g., by renaming file extensions); doing so would be a serious violation.

• Regular Auditing: The ISO conducts or commissions periodic audits of data protection measures. This can include sampling systems to verify that classification labels are correct, that encryption is actually in place, and that access rights in practice match our policy (e.g., running a report of who accessed certain HR files and confirming all names are HR staff). We also test our incident response and identify lessons (like if an audit finds some confidential data was lingering in an unapproved place, we fix it and improve training).

• Compliance Audits: If a client invokes their right to audit our data handling (common in some industries), we will accommodate that. This could involve them reviewing our logs or policies. We keep the necessary documentation (like this policy, training records, access review records, destruction certificates) to demonstrate our controls. Internally, our ISO may simulate a client audit yearly to ensure we’re prepared and all documentation is up-to-date.

• Privacy Audits: Regarding personal data, we maintain records of processing (what personal data we have, where it goes – required by GDPR and others). The Privacy Officer will periodically audit that we are adhering to stated privacy policies (for example, we said we only keep applicant data 1 year – is that being deleted?).

Monitoring and logging, though mainly an IT function, should be known to users – there’s no expectation of privacy for actions on company systems besides the confidentiality of personal content as required by law (we don’t read personal emails, but we do monitor use of company email for policy compliance, etc.). We do this not to intrude but to protect the company and clients. All monitoring is done in accordance with applicable laws and with respect for employee privacy – focusing on security relevant events.

In conclusion, our data protection and privacy efforts combine technical controls, user diligence, and oversight to create a robust defense-in-depth. Every employee and contractor has a role: follow the handling rules, be mindful of privacy, and report issues. By doing so, we not only secure our assets but also maintain the trust placed in us by our clients, partners, and personnel – trust that is reinforced by contractual commitments which we meet through these practices.

5. Network and System Security

This section describes how we secure our IT infrastructure – including networks, servers, endpoints (workstations/laptops), and software – to protect against cyber threats and unauthorized access. These controls ensure we maintain service reliability and fulfill any technical security requirements mandated by contracts or regulations (for instance, maintaining a firewall, up-to-date antivirus, etc., which are often expected as baseline controls by clients).

5.1 Secure Configuration (Hardening) of Systems:

All Company systems are configured securely according to industry-standard hardening guidelines (e.g., CIS Benchmarks) and vendor best practices. Key configuration policies include:

• Remove Unnecessary Services/Software: On servers and workstations, disable or uninstall features that are not required. For example, no web server or database service should run on a machine unless needed. This reduces attack surface. Many contracts implicitly require this by expecting “commercially reasonable efforts to minimize vulnerabilities”. We specifically ensure default admin shares, sample databases, or default accounts are removed or secured.

• Secure Default Settings: Vendors often ship products with insecure defaults (like default passwords, open ports). IT changes all default credentials immediately on installation (e.g., the default admin password on a router). We also configure security settings: enabling host firewalls, turning on audit logging, disabling old protocols (e.g., SMBv1, TLS 1.0/1.1), and setting proper permissions on files and keys. For Windows systems, we apply our Group Policy configurations that enforce security (password complexity, account lockout, etc., as per Section 3.5) and align with many contractual baselines.

• Patching and Updates: All software and firmware must be kept up-to-date with security patches. This includes operating systems, applications, and network device firmware. IT runs a centralized patch management process: critical patches are applied within a short time (typically within 14 days of release, or sooner if actively exploited), meeting or exceeding any contractual patch SLAs (some clients require patching within e.g. 30 days). We track available patches via automated tools and subscribe to vendor security bulletins. For third-party software that cannot auto-update, IT regularly checks for updates (at least monthly). Endpoints (PCs) receive monthly OS patches and frequent browser/app updates through our management system. Systems that cannot be patched (e.g., legacy due to application constraints) are documented as exceptions, require ISO approval, and must have compensating controls (like isolation or additional monitoring) — we strive to eliminate such exceptions as they often violate compliance if left unmanaged.

• Anti-Malware Protection: All servers and workstations run up-to-date anti-malware software with real-time protection. Currently, we deploy a next-generation endpoint protection platform (Microsoft Defender ATP) to all PCs and servers, which is centrally monitored. Definitions are updated at least daily. This protects against viruses, spyware, ransomware, and other malicious code. Many client contracts require the use of anti-malware on any system touching their data. Users must not disable or tamper with anti-virus; attempting to do so triggers alerts. We also run at least weekly full system scans. Email and web gateways have their own malware filters (discussed in 5.3).

• Firewalls and Network Segmentation: The Company maintains network firewalls at appropriate points, including the perimeter and between VLANs internally. The perimeter firewall is configured to deny all inbound traffic that is not expressly permitted and to allow outbound traffic only as needed. Specific client contract requirements (like maintaining a firewall around cardholder data environment for PCI or using access control lists to restrict their data access) are implemented. Internal networks are segmented: e.g., servers are on a separate VLAN from user PCs; sensitive systems (HR, finance) may be on isolated subnets or require jump-box access. This limits lateral movement if a threat arises. Firewall rules and segmentation schemes are reviewed quarterly to ensure least privilege at the network level.

• Secure Baseline for Applications: Application developers and admins ensure that applications (especially web apps) are securely configured. This includes disabling debug accounts, setting secure configurations in app servers (e.g., forcing HTTPS, using secure cookies, etc.), and verifying that credentials or API keys used by apps are stored securely (not in code or public repositories). We follow secure coding guidelines to prevent common vulnerabilities (OWASP Top 10), and do code scans or penetration tests of critical apps (more in 5.5). Many contracts, especially for software development, require adherence to such standards.

• Encryption Everywhere: Beyond the data-specific encryption in Section 4, at the system level we encrypt: laptops (Full Disk Encryption), mobile devices (device encryption through MDM policies), backup tapes (if any, through backup software), and removable drives (all USB drives issued are hardware-encrypted). This ensures that if a device is lost or stolen, data remains secure, fulfilling obligations like “Contractor shall encrypt devices storing Confidential Information”. We confirm encryption is active via device management consoles.

• Secure Cloud Configuration: For cloud resources (IaaS, SaaS), we apply secure settings similarly. E.g., for Azure/AWS VMs: enable OS hardening, restrict management ports, use cloud security groups. For SaaS like Office 365: enforce MFA, disable legacy auth, configure DLP, and set tenant policies aligning with our data handling rules. Cloud admin consoles themselves are protected by strong auth and limited access (only ISO and senior IT can administer our cloud tenants).

IT documents these baseline settings in a hardening checklist for each platform and regularly audits systems against them. New systems must be hardened before production use, and periodically the ISO may have an external firm do a configuration audit to validate our process.

5.2 Network Security and Monitoring:

In addition to firewalls mentioned above:

• Intrusion Detection/Prevention Systems (IDS/IPS): We employ IDS/IPS on the network edge (and in key internal network segments). They inspect network traffic for suspicious patterns or known attack signatures and either alert or block as configured. For example, an IPS will drop packets that match a SQL injection attack signature against our web server. Alerts from IDS go to our SIEM for analysis (Section 5.4). We keep IDS signature sets updated. If a client requires a specific IDS or monitoring of their traffic, we accommodate it (e.g., some government clients might want a dedicated sensor on their segment).

• Secure Remote Access: All remote administrative access (for IT staff or vendors) to our internal network requires connecting via our VPN (with MFA as noted) or using a secure remote desktop gateway. We do not allow remote desktop directly to servers from the internet. Admins must first VPN then RDP, which is logged. Some highly sensitive systems have a jump server (bastion host) that admins must log into (with MFA and logging) and then access the system from there. These measures line up with contract clauses about using secure methods for remote administration.

• Wireless Security: Our corporate Wi-Fi networks use WPA2-Enterprise encryption with individual credentials (linked to AD accounts). Guest Wi-Fi is isolated from internal resources and uses WPA2-Personal with a rotating guest passphrase (changed regularly). We monitor for rogue access points. Through these measures, internal wireless access is as secure as wired, which is important if employees discuss or transmit confidential info over Wi-Fi. In client offices where we work, we use their secure network or ensure our devices use VPN when on untrusted Wi-Fi to maintain confidentiality of our data.

• Logging and Alerting: (See 5.4 for more detail) All critical network devices (firewalls, switches, IDS) send logs to our central log server (SIEM). We have alerts set up for critical events: e.g., multiple denied firewall attempts from one source, or detection of malware by IPS. We tune these alerts to reduce false positives. This continuous network monitoring allows us to respond quickly to potential intrusions, fulfilling commitments to “promptly detect and respond to security incidents”. Additionally, for any network segments used for clients (like a subnet hosting client servers), we can provide them with periodic network security reports if contractually required.

• Penetration Testing: (Overlaps with 5.5, but notable for network security) We conduct external penetration tests at least annually to evaluate the security of our internet-facing infrastructure. If a client requires more frequent tests or specific scans (some require quarterly vulnerability scans by approved vendors, e.g., PCI ASV scans), we comply and share the results/follow-up with them. We also perform internal network vulnerability scans to catch things behind the firewall (details in 5.5).

5.3 Endpoint (Workstation & Device) Security:

• Standard Builds: We maintain a standard, hardened image for company PCs that includes pre-configured security settings: automatic screen lock after 10 minutes of inactivity, USB auto-run disabled, host-based firewall turned on, encryption on, etc. All user laptops and desktops are deployed with this image. Only authorized IT personnel can modify these baseline settings. This ensures every endpoint that may handle confidential or client data meets baseline security (and we can attest to clients that “all devices accessing your data are encrypted and managed”).

• Least Privilege on Endpoints: Users do not have local admin rights on their company laptops by default. This prevents installation of unauthorized software or driver changes. If a power user needs local admin for legitimate tasks, it is granted case-by-case and often via a separate admin account, and logged. Removing admin rights is a key mitigation against malware and is often recommended by regulators and clients.

• Device Management: All endpoints are enrolled in our Mobile Device Management (MDM/EMM) system (including smartphones if they access company email). This allows remote wipe if lost, enforcing PINs on mobile, and pushing security patches/policies to PCs. We maintain the ability to wipe corporate data from personal devices if used for work (users agree to this in our BYOD policy). This is important for fulfilling obligations to protect data on BYOD or to remove data after an employee/contractor leaves.

• Antivirus & EDR: As mentioned in 5.1, every endpoint runs anti-malware with real-time protection. In addition, our endpoint detection and response (EDR) tool watches for suspicious behavior (like a process trying to inject code into another, or rapid encryption of files indicating ransomware) and can automatically block or isolate a machine. If an endpoint is suspected compromised, our system can network-isolate it while still allowing it to communicate with remediation tools, thus containing threats quickly.

• Web Filtering: Laptops and desktops have web filtering agents when off-network (and on-network we use a secure web gateway). This blocks access to known malicious or inappropriate sites. It reduces risk of drive-by downloads and helps employees avoid scams. It’s also part of acceptable use enforcement (no visits to illegal content). Many client orgs ask if we filter web access to prevent malware ingress – we do, extensively.

• Application Control: Where feasible, we employ whitelist or restrict software: e.g., only Company-approved software can run on servers, and on user PCs we block known unsafe apps. If a specialized tool is needed, IT will vet and install it. This ties to license compliance as well (don’t want users installing unauthorized software which could violate license or contract terms).

• Removable Media Control: In addition to encryption mandate, we track usage of USB storage via the endpoint protection console. We can audit what files are copied to USB. Certain highly sensitive systems have USB ports disabled entirely (e.g., servers with health data might have that policy to meet strict regulatory standards). We strongly discourage transferring data via personal drives – use corporate encrypted drives which we manage. If a contract forbids using removable media for their data, we strictly enforce that by technical controls or procedure (like a policy that any client X data must stay on company network drives only).

5.4 Logging, Auditing, and Incident Response Preparedness:

(This overlaps with sections 4.7 and 7, but reinforcing technical logging infrastructure here.)

• Centralized Logging (SIEM): We have a Security Information and Event Management (SIEM) system where logs from critical servers, network devices, security tools, and certain applications aggregate. The SIEM correlates events and highlights anomalies. For example, it might alert if an account logs into a server it never accessed before at 3 AM (could be lateral movement by an attacker). We ensure logs are time-synchronized via NTP so correlation is accurate. We retain logs as long as needed (at least 1 year online, older archived) and as required by contracts/regulations (some require up to 7 years for certain logs).

• Log Review: The IT Security team (or our managed SOC provider) reviews security logs daily for critical events and at least weekly for general anomalies. High-risk systems (like those containing client critical data) may have automated real-time alerting to on-call staff for certain triggers (to satisfy any contract stipulation that we will “notify Client immediately upon detection of a likely breach” – our monitoring aims to detect and alert promptly).

• Audit Trails: We maintain audit trails for key transactions, especially on financial or sensitive systems. For instance, our ERP logs who approves payments. These audit trails protect data integrity and help us or clients investigate if something is amiss.

• Incident Response Integration: Our monitoring and logging directly feed into our incident response process (Section 7). When suspicious activity is logged, the IR team is alerted to investigate. This proactive detection is part of our contractual duty to use reasonable security measures to identify intrusions.

• Periodic Audits: Aside from automated monitoring, we conduct formal audits (internally or via third-party). This may include network vulnerability assessments (quarterly internal and external scans – required for PCI and good practice; results are reported to ISO for remediation) and system configuration audits (ensuring GPO settings haven’t drifted, etc.). If clients require external compliance audits (like SOC 2 Type II or ISO 27001 certification), we support those by providing evidence of our network and system controls as described here.

5.5 Vulnerability Management and Penetration Testing:

We have a robust process to find and fix vulnerabilities:

• Vulnerability Scanning: We run automated vulnerability scans on our internal network at least monthly and on all external-facing systems at least weekly. We use enterprise tools to scan for missing patches, misconfigurations, and common weaknesses. For web applications, we run web vulnerability scanners after updates. If a client environment is in scope (e.g., we host an app for a client), we ensure it’s included. We promptly remediate discovered high-risk vulnerabilities. Our standard is to remediate critical vulns within 1 week and high within 2 weeks (these meet or exceed common client requirements; if a contract specifies a timeframe, we adhere to that).

• Penetration Testing: At least annually, and more often for major changes, we engage an independent security firm to perform penetration testing of our environment – both external (trying to breach from internet) and internal (assuming perimeter is bypassed, can they escalate?). They also test critical web applications that we develop or host. Any findings are analyzed and fixed. We share relevant results with stakeholders as needed (for instance, if a pen test revealed an issue on a system with client data, we would inform the client that we found and fixed a vulnerability that could have affected them, per transparency commitments). Some contracts (especially with larger enterprises or government) explicitly require annual pen tests or even that the client can conduct their own test on our systems. We coordinate with them to allow it under controlled conditions, and then address any issues found as though it were our own test.

• Patch Management (revisited): The output of scanning drives our patching (section 5.1 covers ensuring updates). We use a risk-based approach: vulnerabilities with known exploits or involving sensitive systems get priority. If a patch might disrupt something, we schedule downtime or find interim mitigations (like a firewall rule to block an exploit path) until patching. We maintain a log of applied patches – sometimes clients audit that to ensure we’re up-to-date as promised.

• Configuration and Code Review: For custom systems, we perform code review and security testing as part of SDLC. We also do configuration reviews after major deployments (ensuring new systems follow our baseline – see 5.1). For example, after deploying a new SQL server, an admin double-checks that only required services are running, weak ciphers disabled, etc. This catches any misconfigurations that scanners might not flag clearly.

• Remediation Tracking: The ISO keeps a tracker of all identified vulnerabilities and their remediation status. Issues are categorized by severity. This is reviewed in security committee meetings (which include management) so there is oversight. If any vulnerability cannot be fully remedied (e.g., vendor has no patch yet), we document how we’re mitigating the risk. This tracker can be shared with clients or auditors if needed to demonstrate we systematically address issues (some clients ask during vendor risk assessments for evidence of vulnerability management – we can show trends like fewer critical vulns over time, etc. as proof of our effective program).

• Change Control and Testing: We integrate vulnerability considerations into change management. When implementing changes or new software, we assess potential new vulnerabilities and test to ensure none are introduced. E.g., if we upgrade a web server, we run a quick scan after to ensure no configuration got reset to insecure default. This proactive stance is part of our effort to maintain a secure environment continuously, not just at audit times.

By diligently following these network and system security practices, Horizon Technology Studio provides a secure foundation for all information handling. We significantly reduce the likelihood of breaches or service disruptions, thereby protecting our commitments to clients (like maintaining confidentiality and uptime) and ensuring compliance with any security frameworks we align with. All employees, especially IT and those with technical roles, must adhere to these standards. Non-IT staff should be aware that these behind-the-scenes measures (firewalls, scans, etc.) are in place, and support them by not attempting workarounds or introducing unapproved devices/software which could undermine our security.

In summary, our networks and systems are configured, monitored, and updated to a high security standard. We frequently test ourselves through scans and third-party audits to identify and fix any weaknesses. This proactive approach helps us avoid incidents and also gives assurance to clients/regulators that our environment is well-controlled (we can show them policies, scan reports, pen test certificates, etc., demonstrating our due diligence).

6. Physical Security and Environmental Controls

While much of information security focuses on digital safeguards, physical security of our offices, facilities, and hardware is equally important for protecting information. Unauthorized physical access can lead to data theft or damage just as hacking can. The Company implements physical security measures to control access to offices and sensitive areas, protect equipment from environmental threats, and ensure secure handling of hard-copy materials. These measures help fulfill obligations such as maintaining a secure workplace for any client information we hold on-site and protecting hardware that might store confidential data.

6.1 Facility Access Controls:

• Office Entry: Our office doors are secured by an electronic badging system. Only authorized personnel (employees, long-term contractors) are issued access badges to enter. Badges are individually identified and access logs are kept. Visitors must ring or be admitted by an employee – we do not prop open secure doors or allow piggybacking (following someone through without using a badge). Reception (or first employee noticing) will politely challenge any unknown person without a badge in a secure area. All employees are trained not to let strangers tailgate behind them and to securely close doors. These practices ensure that Confidential information within the office (on screens, desks, conversations) is not exposed to the public, and align with requirements to restrict access to authorized persons. During working hours, main doors may be unlocked in public reception areas, but interior doors to office suites remain badge-secured.

• Visitor Management: Every visitor (including job candidates, vendors, clients, or personal guests beyond lobby) must sign in at reception (name, company, person visiting, time in/out) and be escorted at all times by an employee. They receive a “Visitor” badge that they must wear. Visitors are not allowed to wander unescorted. The host employee is responsible for their visitor’s compliance (ensuring they don’t peek at confidential docs, etc.). Visits by maintenance or janitorial personnel off-hours are either escorted or pre-authorized by management with background checks as needed (our cleaning crew are vetted via the building). Visitor logs are retained for at least 90 days; this helps if we need to investigate a physical security incident or respond to a client’s site security questionnaire (some ask if we log visitors). Visitors are only permitted in areas relevant to their visit – e.g., a client touring our facility may see the development area but will not be taken into the server room or HR file room.

• Sensitive Areas Restricted: Certain areas with especially sensitive information or equipment have additional access restrictions. For example, the server/network equipment room is locked at all times and accessible only to IT staff (and executives) via a separate key or badge access (with codes). Similarly, file cabinets containing personnel records or customer contracts are kept in locked offices; only HR (or Legal) has keys to those. Keys to locked areas are issued on need basis and a key log is maintained. Combination locks or alarmed doors are used where appropriate (our server room has an alarm if opened without authorization). These steps safeguard against insider curiosity or contractor access beyond their scope, which might otherwise inadvertently breach confidentiality.

• Access Termination: Physical access for departing personnel is revoked promptly along with IT access (HR collects their badge at exit and IT deactivates it in the system the same day). If an employee is terminated suddenly, security will be alerted to ensure they are escorted and their badge disabled concurrently to prevent re-entry. We also re-key or change codes if a high-risk employee had access to secure areas (though normally just deactivating badge works). These measures align with the digital account termination process to ensure no continued facility access after leaving.

6.2 Environmental Security:

• Alarm Systems: Our office is equipped with an alarm system that is armed outside business hours. It covers motion detectors and door contacts. Alerts from the alarm go to a security monitoring service and designated managers. This deters unauthorized off-hour access and is part of compliance for places where sensitive data is stored (some contracts require an intrusion alarm if hosting certain data). Staff who need after-hours access have codes and must arm/disarm properly – they are briefed on this procedure.

• Video Surveillance: Key entry points and critical interior areas (like server room entrance) are monitored by CCTV cameras. Footage is recorded and kept ~30 days. Cameras are not placed in private areas (no bathrooms or personal desks, just general areas and doors). The presence of cameras is disclosed via signage as required. In case of an incident (e.g., theft of a laptop), we review footage to support investigation. This can also provide evidence if we ever need to show a client that only authorized personnel entered a secure room, etc. We limit who can view camera footage (Facilities manager, ISO, or leadership) to protect privacy.

• Fire Protection: Our office building has fire alarms and suppression (sprinklers) as per code. In server areas, we have placed fire extinguishers (CO2 or clean agent type) nearby so that a small electrical fire can be addressed without damaging equipment. Critical equipment is elevated off the floor to avoid minor flooding. We back up data offsite specifically in case a fire destroys on-prem systems. Employees are trained on basic fire response (location of extinguishers, alarm pull stations, evacuation routes). During drills or alarms, they must secure confidential documents if time permits (e.g., lock file cabinets) and then evacuate.

• Climate and Power: The server/network room has dedicated cooling and an Uninterruptible Power Supply (UPS) to maintain stable environment. Overheating or abrupt power loss can lead to data corruption or downtime affecting clients. We monitor server room temperature/humidity and get alerts if out of range. UPS units provide battery backup so servers can ride through short outages or safely shut down during extended ones. Some critical network gear also connects to building generator circuits if available. These controls help meet any service level or uptime obligations by protecting hardware from damage and keeping systems running through moderate disruptions.

• Clean Desk Policy: To reduce chance of inadvertent disclosure or loss, we implement a clean desk policy. Employees are required to clear sensitive papers from their workspace or lock them up when leaving for extended periods and at end of day. Documents containing Confidential information should not be left in the open where unauthorized persons (or visitors) could see them. This reduces risk of insider curiosity or visitor snooping. Likewise, whiteboards used for confidential discussions (like client architecture or credentials) should be erased after use. Managers enforce this policy with periodic walk-throughs. Not only is this good security, it’s often asked about in security audits – we can confirm we do practice it.

6.3 Equipment Security:

• Workstation Positioning: Within offices, screens displaying sensitive info should not face public areas or be easily visible to visitors. We provide privacy filters to employees handling highly confidential material (like HR or finance) so even nearby coworkers can’t shoulder-surf.

• Laptops and Mobile Devices: Employees must secure portable devices. Laptops should be locked with a cable lock at workstations if left, or locked in drawers. When taking laptops offsite, never leave them unattended in public or in a car in plain sight. If a laptop or phone is lost or stolen, the employee must report it immediately so IT can remote wipe it. All laptops being taken on travel must be encrypted (which they are by default) and have up-to-date endpoint protection. If crossing international borders with devices containing client data, consult the ISO – there may be guidelines to follow to avoid seizure issues (some clients forbid carrying their data to certain countries).

• Media and Printed Material: Physical media (USBs, CDs) containing sensitive data must be treated as Confidential. They should be labeled and locked when not in use. We maintain a log if someone issues such media (e.g., IT logging out an encrypted USB drive to a user, and logging it back in or confirming destruction). Hard copy documents should similarly be tracked within departments – e.g., numbered copies for board documents, collected afterward. For particularly sensitive projects, we can adopt a “no paper” rule (only electronic, or if printed, must be shredded right after meeting).

• Hardware Disposal: When disposing of or returning any hardware (PCs, printers with memory, phones), IT will wipe or purge data (as detailed in 4.5). We maintain chain-of-custody for devices until they are confirmed wiped or destroyed. A certificate of destruction for old hard drives is kept on file (addresses compliance with any contract clause requiring evidence of media destruction for data stored on it).

• Personal Device Use: As per our BYOD policy, any personal device used to access Company email or data must be enrolled in our MDM. Personal devices that cannot support our security requirements (e.g., outdated OS that can’t be encrypted) are not allowed to connect. We reserve the right to block or wipe company data from personal devices if policy violations occur. This policy is communicated to employees and is usually acknowledged as part of on-boarding. Many clients require that any device with their data on it be subject to such controls, so our BYOD approach enables us to meet that by enforcing encryption, remote wipe, etc., on any device with client data.

6.4 Off-Site and Travel Considerations:

• Remote Work Locations: Employees working from home or client sites must maintain equivalent physical security. At home, they should have a private, dedicated workspace not accessible to others. Confidential papers at home should be kept out of roommates’ or family’s view and stored securely (preferably locked). Conversations about sensitive matters should not be done in public (no discussing client confidential info on a train or coffee shop loudly). When working at a client site, follow the client’s physical security rules as well (like wearing their badge, locking their office if leaving). Any disposal of client documents should ideally be through the client’s shredding bins unless brought back to our office for secure disposal.

• Travel: When traveling with Company devices or data, employees must remain vigilant. Laptops should not be checked in luggage, and should not be left in hotel rooms unsecured. Use the room safe or keep the device on your person. For extremely sensitive trips, IT can provide loaner devices with minimal data (or advise carrying encrypted USB with data and not storing on laptop). Also, be cautious using public Wi-Fi – always use our VPN to access Company resources when on untrusted networks. This is part of our contractual commitment to secure remote connectivity. If an employee suspects their device was tampered with during travel (e.g., unusual behavior after leaving it in a hotel), they must report it so IT can inspect/rebuild it.

6.5 Third-Party Facilities:

If we collocate equipment in an external data center or use cloud providers, we rely on their physical security controls (badges, guards, cameras). We choose reputable providers that meet standards (SOC 2, ISO 27001) and include in contracts that they maintain proper physical security. We review their audit reports annually (Section 9 covers vendor security). For client-owned sites where we maintain equipment (like a client’s branch office where we placed a server), we ensure via contract/MOU that the client will provide suitable physical protections (locked room, limited access) – essentially the client acts as caretaker under our guidance, and we document that in our risk assessment.

In essence, our physical security measures create a secure environment that complements our technical controls. Employees must uphold these practices (wear badges, challenge unknown persons, lock up assets, etc.), as physical lapses can undermine all other security. Many breaches begin with something simple like stolen equipment or an intruder plugging into a network – our controls aim to prevent those. We periodically test aspects (e.g., unannounced visitor tailgate tests) to ensure vigilance. By doing so, we adhere to both common industry safeguards and specific contract clauses requiring physical security for confidential info (some contracts list facility security measures we confirm we have, which we do as described). Physical and environmental security is everyone’s responsibility – if you see something risky (like a door left ajar or water leak near equipment), report it so we can act.

7. Incident Response and Business Continuity

Despite preventive measures, security incidents or disruptions may occur. Horizon Technology Studio has established incident response and business continuity plans to ensure we handle such events effectively, minimize damage, and resume normal operations quickly. This not only reduces impact but also helps fulfill any contractual obligations around incident handling (such as notifying clients or providing post-incident reports) and meeting service level agreements for uptime.

7.1 Incident Reporting and Identification:

• Definition of an Incident: A security incident is any observed or suspected event that could compromise the confidentiality, integrity, or availability of information or systems. Examples include: a lost/stolen device, detection of malware on a computer, unauthorized use of a login account, disruption or ransomware on a server, suspected data leak, or any policy violation that could lead to a breach (like an employee emailing sensitive data to a personal account). Also included are any failures of critical controls (like finding a firewall down or encryption off). If unsure, staff should err on the side of reporting it.

• Immediate Reporting: All employees, contractors, and third parties using our systems are required to report any security incident or weakness immediately to the Information Security Officer or IT helpdesk (which then alerts the ISO). We provide multiple channels: a dedicated security incident email (support@horizontechnologystudio.com), an emergency phone extension, and a Teams channel, to encourage prompt reporting 24/7. The sooner we know, the faster we contain it – which is also key to meeting breach notification deadlines (some contracts require notification within 24 hours or “without undue delay”). There is no penalty for reporting a false alarm in good faith; there can be serious consequences for failing to report an actual incident or trying to hide it.

• Initial Response Team: The Company has an Incident Response Team (IRT) led by the ISO, including IT Security, IT ops, and relevant managers. On notice of an incident, the ISO (or designated Incident Manager) will activate the IR plan and assign roles (lead handler, communications lead, etc. depending on severity). We categorize incidents by severity (Low, Medium, High/Critical) to prioritize response. For example, a suspected major breach or ransomware outbreak is Critical – all hands on deck immediately, whereas one user’s malware infection might be Medium and handled by IT support with ISO oversight.

• Containment First: Our IR process prioritizes containment of the threat to prevent further damage. For instance, if a workstation is suspected compromised, we isolate it from the network at once (using our EDR tool or by unplugging it). If credentials are stolen, we disable them right away. These actions correspond to our obligations to mitigate incidents swiftly – clients expect us to “immediately contain and mitigate the incident to limit exposure”.

7.2 Incident Response Process:

We follow a structured IR plan (based on NIST/SP800-61 phases: Preparation, Detection, Containment, Eradication, Recovery, and Lessons Learned):

• Detection & Analysis: The IR team investigates reported indicators. They gather information: logs, alerts from SIEM, talk to the reporter, run scans, etc. to confirm if an incident occurred and determine its scope. Forensic analysis may be done (especially for data breaches – e.g., checking system logs to see what files an intruder accessed). We document all findings in an incident log. If personal data or client data is involved, we note what types and volume (this is needed for notifications). Throughout this phase and others, we keep a communication log of who did what and when – this is vital for later reporting.

• Containment: The team isolates affected systems or segments to prevent further spread. Examples: quarantining infected machines, taking compromised systems offline, changing DNS to sinkhole malicious traffic, applying temporary firewall blocks. If an incident is ongoing (like active ransomware), we might disconnect the entire site from internet to halt it, then bring up segments after cleaning. Such containment actions are taken rapidly – our IR training drills emphasize swift containment decisions, even if it means some downtime. Many client contracts would prefer a short outage to stop a breach rather than prolonged silent compromise. If client systems or data are affected, we coordinate containment with them (particularly if system is on their network – we may advise them to isolate a server). We also consult any contractual obligations at this stage: e.g., do we need client approval to shut something down? Usually not in emergencies, but we check contract language to be sure we handle any client-owned components appropriately.

• Notification (Internal and External): The ISO informs senior management of high-severity incidents right away. If the incident potentially involves client data or services, we follow contract requirements to notify that client promptly (often within 24 hours or even immediately for severe breaches). Even if still investigating, an initial notification with known facts is sent (e.g., “We experienced a cybersecurity incident on [Date]; your data on [System] might be affected. We’ve contained it and are investigating, will update in 24 hours.”). We prefer to over-communicate rather than under, as trust is key. If regulated personal data was breached, our Privacy Officer (or ISO) will also prepare to notify regulators and individuals as required by law, in coordination with the client if it’s their data (under GDPR, as a processor we notify the controller (client), who notifies authorities; under some state laws if it’s our data, we notify authorities and affected people). All notifications are reviewed by legal counsel and management before sending. We also notify law enforcement if appropriate (e.g., a large theft of data or a cyberattack from a known criminal group). Contracts sometimes require notifying an insurance carrier or other third party – we ensure all required notices happen.

• Eradication: After containment, we identify and eliminate the root cause. This involves removing malware, closing exploited vulnerabilities, updating firmware, or in some cases rebuilding systems fresh. For example, if a web server was compromised via an unpatched flaw, we not only patch that flaw but also thoroughly clean or rebuild the server to ensure no backdoors remain. We reset credentials that may have been compromised. If personal data was exfiltrated, we work to understand exactly what and ensure the attackers’ access is cut. Sometimes third-party forensic specialists are engaged (e.g., if credit card data is breached, PCI rules often mandate PFI forensic investigation). We cooperate fully and preserve evidence (we do not wipe systems until forensic imaging is done).

• Recovery: We carefully bring systems back online and restore data from backups if needed. This step is done after verifying the threat is eradicated and systems are secure (patches applied, passwords changed, etc.). We monitor the restored systems closely for any sign of recurrence. If data was corrupted or lost, we retrieve backups to meet continuity goals (e.g., RTOs defined in our BC plan – see below). We validate that systems are functioning normally and that security controls (like monitoring) are back in operation. For significant incidents, we might do phased recovery (e.g., restore network one segment at a time, watching for anomalies). If client services were impacted, we update them on recovery progress and provide necessary assistance (if our system outage affected them, maybe we offer an alternate solution until fully back). Recovery isn’t complete until operations are at normal state and both our team and any affected clients are satisfied it’s stable.

• Business Continuity Activation: In parallel to incident response (particularly for availability incidents like natural disasters or major outages), we activate our Business Continuity Plan (BCP). Business Continuity ensures critical operations continue or resume in timely fashion. For example, if our main office is unusable due to a flood (physical incident), our BCP might direct employees to work from alternate locations (their homes or a temporary office) and IT would spin up cloud infrastructure for key servers. We prioritize critical services (in line with any service level agreements). The BCP includes a list of critical systems and their Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Our continuity strategies include having offsite backups (so we can restore data at a new site) and having cloud-hosted collaboration tools (so even if office is down, email/Teams work). We have tested these plans (e.g., an annual disaster recovery drill). Therefore, even amidst an incident, we can continue essential work for clients (perhaps in degraded mode, but not completely halt), which helps meet contract commitments to service delivery. For instance, if our primary data center went down, we know from planning that we can restore most client-facing apps from backups to cloud within X hours – that timeframe is often stated in contracts (like an RTO for disaster). Because we’ve prepared, we can deliver on that.

• External Communications: Beyond direct client notifications, severe incidents may prompt communication to others: employees (internal memo to be vigilant, or with instructions if systems are down), possibly media or public (only via authorized spokespeople, typically management or PR, and if the incident is public or needs disclosure). We coordinate such messages carefully to ensure consistency, accuracy, and no unauthorized person speaks on company’s behalf. This also ties to contract/moral obligations – being transparent with clients, and not making public statements that conflict with what we privately tell clients or regulators.

• Lessons Learned: After resolving an incident, the IR team holds a post-mortem meeting to review cause, response, and improvements. They produce an incident report documenting: timeline, impact, root cause, containment steps, data affected, and corrective actions. This report is shared with Senior Management and, for major breaches, with affected clients. Indeed, many contracts require a formal incident report to the client within a set time (like 5 business days of incident closure), including what happened and what we’re doing to prevent recurrence. We comply by delivering these reports. We then implement the recommended changes – e.g., if the breach occurred due to an unpatched server, we might improve patch management processes; if response was slow due to incomplete contact lists, we update our IR procedures. We update this policy or related policies if needed. Lessons might include additional training for staff if human error caused the incident (like re-training employees if a phishing email succeeded).

• Plan Updates and Testing: We refine the incident response and BCP plans regularly (at least annually or after any significant incident). We test elements of these plans via drills: e.g., an unannounced phishing drill to test response, or a tabletop exercise simulating a ransomware attack. Each test’s findings are used to improve readiness. All employees involved in IR have been trained on their roles. This preparation and continuous improvement is often something clients inquire about – we can demonstrate it through training records and test summaries, which many sophisticated clients appreciate (or even require evidence of).

7.3 Business Continuity Plan (BCP) Highlights:

• Critical Functions Identification: Our BCP identifies key business processes (customer support, project delivery, IT infrastructure, payroll, etc.) and the resources needed to sustain/recover them. For each, we have determined acceptable downtime (RTO) and acceptable data loss (RPO). For instance, email and internal communication have near-zero RTO for us to operate, so we use cloud email to ensure continuity; a less critical system like the marketing file archive might be okay to restore within 48 hours from backup. We ensure these targets align with any client-agreed Recovery Timeframes in contracts (if a contract for hosting a service says it must be back in 24 hours after disaster, we set our plan to meet that or negotiated a feasible number).

• Alternate Site/Remote Work Arrangements: If our office is inaccessible, employees are equipped to work remotely. The pandemic era solidified our remote capabilities: VPN, collaboration tools, and cloud apps allow most work to continue from home. For functions that cannot be remote (maybe a specific lab or on-prem server management), we have an arrangement with a nearby co-location or partner to use space/equipment if needed. We keep an updated contact list (including personal contacts) for all staff to reach them off-hours or if corporate systems are down (a copy is with HR and ISO in hard copy too). We test call trees occasionally.

• Backups and Offsite Storage: As detailed in Section 4.5, we maintain offsite backups for data. We also keep duplicates of important documentation (like this policy, key contracts, etc.) in a secure cloud repository accessible during a continuity event.

• Coordination with Clients and Vendors: Our BCP includes communications plan for clients – if an incident affects them (like our data center outage impacting their service), we will notify them promptly with status and interim solutions. If client facilities are impacted but our services still run, we reach out to see how we can assist from our side. We also coordinate with critical vendors during continuity events (for e.g., if our internet is down, we work with telecom provider for restoration while possibly switching to a backup line if we have one).

• Periodic BCP Testing: We conduct a BCP drill at least annually (which might be combined with IR drill). For example, simulate the loss of our main office and see how quickly we can have everyone work from alternate locations and restore IT services from backups. We document results and improvements. Clients sometimes request evidence of BCP tests or might even participate if it involves them. We keep summary reports of each test to show readiness.

7.4 Post-Incident Client Support and Compliance:

After a major incident (especially one that triggered contractual notifications), we often owe follow-up to clients:

• Provide a written incident report and root cause analysis within the timeframe specified (commonly 5-10 days).

• Implement additional safeguards requested by client (e.g., they might ask for more frequent status updates, or that we engage an independent auditor to verify the fix – we do so to rebuild trust).

• Possibly allow the client to audit or inspect evidence of the fix (some contracts allow client audit after security incidents).

• If service credits or penalties apply due to downtime beyond SLAs, coordinate with finance to credit as required (we aim to avoid reaching that point by quick recovery, but if it’s in contract and applicable, we honor it).

• Evaluate if contract updates are needed: e.g., after an incident, a client might amend our contract to mandate a specific new control – we cooperate in good faith to amend the agreement and then implement the control.

7.5 Continuous Improvement and Training:

We incorporate lessons from incidents and tests to continually improve policies, training, and technical controls. For example, after a simulated phishing exercise, if certain departments did poorly, we do focused training there. If an actual incident revealed a gap (like unclear decision authority at 2 AM), we adjust our IR plan (maybe designate an on-call executive). This iterative improvement keeps our incident response agile and effective. It also demonstrates, especially in any post-incident report to clients or regulators, that we are learning and reducing the chance of recurrence.

By maintaining a robust incident response and continuity capability, Horizon Technology Studio not only minimizes harm from incidents but also satisfies obligations to act promptly and transparently in the face of adversity. Employees should remember: timely reporting and cooperation during incidents are not just internal policies, but often legal duties (e.g., under data breach laws and contracts). We rely on each person to fulfill their role in these plans if and when called upon. Through preparedness, we protect our company’s interests and those of our clients, preserving trust even when things go wrong.

Conclusion:

This Information Security Policy integrates our operational security practices with our compliance and contractual obligations. All employees, contractors, and third parties working with Horizon Technology Studio must adhere to it. It will be reviewed and updated at least annually, or after significant changes or incidents, to ensure it remains aligned with current risks and requirements.

By following this policy, we create a secure environment for our business operations and honor the commitments we have made to our clients, partners, and regulators regarding the protection of information. Security is not one person’s job – it is a collective responsibility. Thank you for doing your part to keep Horizon Technology Studio secure and successful.

References: Internal Policy Manual, Horizon Technology Studio LLC Master Service Agreement & General Terms v2025.1 (sections on confidentiality, security, incident response); Industry Standards (NIST CSF, CIS Controls). (Detailed citation of sources is maintained in our internal documentation repository.)