Contact Us Security Policies
Kingfield Software

Security Policies

Acceptable Use Policy

Effective Date: 10/29/2025
Applies To: All users of software provided by Kingfield Software (“Company”).

1) Purpose & Scope

This Acceptable Use Policy (“Policy”) governs your access to and use of any Kingfield Software applications, related APIs, and any underlying infrastructure (including our cloud environment). By using the Service, you agree to comply with this Policy and all applicable laws and regulations. This Policy applies to all users, accounts, data, and integrations associated with the Service.

2) Account & Security Responsibilities

  • Accurate information: Provide true, complete, and current registration details.
  • Access control: Keep credentials (passwords, API keys, access tokens, MFA codes) confidential. You are responsible for all activities under your account.
  • Multi-factor authentication (MFA): Where available, you must enable MFA.
  • Security best practices: Install updates promptly, use supported browsers/clients, and maintain reasonable endpoint security.
  • Incident reporting: Notify Company immediately at info@kingfieldsoftware.com if you suspect unauthorized access, account compromise, or data exposure.
Cloud note: The Service is hosted on Amazon Web Services (AWS). Company uses industry-standard controls (e.g., encryption at rest/in transit, network segmentation, logging/monitoring) to protect the Service. You must not attempt to bypass or degrade these controls.

3) Prohibited Uses

You may not use the Service to:

  1. Break the law or infringe rights
    • Violate any applicable law or regulation (including export controls, privacy, IP, and data-protection laws).
    • Infringe, misappropriate, or violate intellectual-property or privacy rights.
  2. Threaten security or integrity
    • Probe, scan, or test the vulnerability of the Service, underlying network, or any AWS component without written authorization.
    • Bypass, disable, or interfere with security or access-control mechanisms.
    • Distribute malware, ransomware, spyware, or other harmful code.
  3. Abuse resources or disrupt operations
    • Launch denial-of-service (DoS/DDoS) attacks; overload or materially degrade the Service or its AWS resources.
    • Use automated means (bots, scrapers, crawlers) that exceed reasonable request rates or violate our robots or API usage guidelines.
    • Spin up or route unrelated workloads via the Service or attempt crypto-mining.
  4. Transmit harmful or unlawful content
    • Post or transmit content that is illegal, defamatory, harassing, threatening, hateful, discriminatory, sexually explicit involving minors, or otherwise objectionable.
    • Share content that contains personal data or sensitive information without proper authorization and lawful basis.
  5. Misrepresent or misuse the Service
    • Impersonate any person or entity, or falsely state or misrepresent your affiliation.
    • Use the Service to create or distribute spam, unsolicited or bulk messages, or deceptive/affiliate traffic.
  6. Violate third-party terms
    • Use the Service in a way that causes Company to violate its agreements with service providers (including AWS), data providers, or licensors.

4) Data Protection & Privacy

  • Your data responsibilities: Only upload, process, or share data you have the lawful right to use. Classify and minimize personal data; avoid uploading special categories of data unless explicitly permitted by agreement.
  • Sensitive data: Unless expressly covered by a separate agreement (e.g., BAA, data-processing addendum), do not submit regulated data such as PHI, PCI card data, or government-classified data.
  • Regionality: Do not force data residency or cross-border transfers that conflict with our documented data-handling practices or your agreements with us.

5) API & Integration Terms (if applicable)

  • Keys & rate limits: Keep API keys confidential. Respect published rate limits and fair-use thresholds.
  • Output handling: Do not cache, redistribute, or resell API outputs except as allowed by your agreement and applicable law.
  • Attribution & restrictions: Follow any attribution, branding, and third-party data-source restrictions we provide.

6) Monitoring & Enforcement

  • Monitoring: Company may monitor use of the Service (e.g., logs, metrics) to maintain performance and security, and to verify compliance with this Policy.
  • Investigation: Company may investigate any suspected violation. You must reasonably cooperate.
  • Remedies: Company may remove or disable content, throttle or block traffic, suspend or terminate accounts, and report unlawful activity to authorities, in its reasonable discretion.
  • Costs: You are responsible for any costs, damages, or liabilities resulting from your violations (including harm to the Service, AWS environment, or third parties).

7) Reporting Violations & Security Issues

Report suspected violations, security incidents, or abuse to:

  • Email: info@kingfieldsoftware.com
  • Details to include: account ID, timestamps (with timezone), source IPs, relevant request IDs or log excerpts, and a description of the behavior.

8) Uptime, Support & Changes to the Service

  • Support: See our Support Policy at kingfieldsoftware.com/support for support hours and channels.
  • Changes: Company may modify or discontinue features to improve security, performance, or compliance. Material changes will be communicated in the application where practicable.

9) Suspension & Termination

Company may suspend or terminate access immediately if: (a) you breach this Policy or applicable agreements; (b) your use creates a security risk or operational burden; or (c) required by law or service-provider terms (including AWS). Upon termination, your right to access the Service ceases, and we may delete or disable access to your content per our data-retention policy and applicable law.

10) No High-Risk Use

The Service is not designed for, and you must not use it in, high-risk environments (e.g., life support, critical infrastructure, emergency services, or safety-critical systems) where failure could lead to injury, death, or severe environmental or property damage, unless expressly permitted by a written agreement.

11) Export Controls & Sanctions

You must comply with applicable export, re-export, and sanctions laws. You may not use the Service if you are located in, or are a national of, a country or region subject to comprehensive sanctions, or are on a restricted-party list.

12) Third-Party Services

Where the Service integrates with third-party services (including AWS), you must comply with those services’ terms and use them only as permitted. Company is not responsible for third-party services it does not control.

13) Policy Changes

We may update this Policy from time to time. The “Effective Date” above reflects the latest update. Continued use of the Service after changes become effective constitutes acceptance of the updated Policy.

14) Contact

Company: Kingfield Software
Address: 4015 Pillsbury Ave S., Minneapolis, MN 55409
Email: info@kingfieldsoftware.com
Security/Abuse: info@kingfieldsoftware.com, info@kingfieldsoftware.com

Access Control Policy

Effective Date: 10/29/2025
Applies To: All employees, contractors, and third parties with access to Kingfield Software systems, data, and services.

1. Purpose

The purpose of this Access Control Policy (“Policy”) is to ensure that access to Kingfield Software information systems, applications, and data—whether hosted on-premises or in the cloud (including AWS)—is granted only to authorized individuals based on business need, least privilege, and security best practices. This policy supports the protection of the confidentiality, integrity, and availability of Company information assets.

2. Scope

This Policy applies to all systems and services owned, managed, or hosted by Kingfield Software, including AWS accounts, production and development environments, and third-party SaaS integrations. It applies to all employees, contractors, vendors, or partners who access Company systems, networks, or data.

3. Principles

  • Least Privilege: Access is limited to the minimum level required to perform assigned duties.
  • Need-to-Know: Access to data is based on legitimate business needs.
  • Separation of Duties: No individual should be able to perform conflicting roles or activities.
  • Accountability: All access is traceable to a unique individual or service identity.
  • Timely Revocation: Access is removed promptly when no longer required.

4. Roles and Responsibilities

  • Information Security Officer (ISO): Defines and enforces access control standards, conducts periodic access reviews.
  • System Owners / Application Owners: Approve user access to their systems and ensure role-based access is correct.
  • IT / DevOps Team: Implements and maintains access control mechanisms and logs.
  • Managers / Supervisors: Approve employee access requests and verify legitimate business need.
  • Users: Maintain the confidentiality of credentials and report suspicious activity immediately.

5. Access Management Lifecycle

5.1. User Registration & Provisioning

All new user accounts must be requested via the formal Access Request Process. Account creation must be approved by the user’s manager and relevant system owner. Temporary accounts must have defined expiration dates. Shared accounts are prohibited except for controlled service accounts.

5.2. Authentication

All users must authenticate using unique credentials. MFA is required for all privileged accounts and for access to production or cloud environments. Passwords must meet the Company’s Password Policy. Service accounts and API keys must be rotated regularly.

5.3. Authorization & Role Management

Access is role-based or attribute-based where supported. Roles define functional permissions aligned to job duties. Elevated privileges must be tightly restricted and approved by the ISO.

5.4. Access Review

Access reviews are conducted quarterly for all production and sensitive systems. Review includes user lists, role assignments, and privileged accounts. Exceptions or unused accounts are revoked promptly.

5.5. Revocation & Termination

Upon termination or role change, HR notifies IT within 24 hours. IT disables user accounts and removes access from all systems, including AWS IAM, VPN, SSO, and third-party tools. Credentials are revoked or rotated.

6. AWS-Specific Access Controls

Access to AWS Management Console must be via individual IAM users or federated SSO; root account use is prohibited except for emergencies. MFA is mandatory for all console users and root accounts. AWS IAM policies use least privilege principles. CloudTrail logs are retained, and KMS keys are rotated annually.

7. Network & Remote Access Controls

VPN or secure channels (TLS 1.2+, SSH) must be used for all administrative access. Access to production environments is limited to authorized personnel via secure bastion hosts. Remote work requires disk encryption, patches, and endpoint security.

8. Third-Party & Vendor Access

Third parties requiring access must sign confidentiality agreements. Access is granted only for the duration and scope required. Vendor activity is monitored and logged.

9. Monitoring & Logging

All authentication and access events are logged and retained. Anomalous activity triggers security alerts. Logs are centrally collected and monitored for analysis.

10. Policy Compliance

Violations of this Policy may result in disciplinary action, termination of access, and/or legal action. Compliance is verified through audits and monitoring.

11. Policy Review & Maintenance

This Policy is reviewed annually or upon significant changes to infrastructure or regulation. The Information Security Officer maintains the policy and related procedures.

12. Contact

Information Security Officer
Charles Weed
Email: info@kingfieldsoftware.com
Phone: +1 651-398-7580

© 2025 Kingfield Software. All rights reserved.

Business Continuity Policy

Effective Date: 10/27/2025
Applies To: All departments, systems, and personnel of Kingfield Software.

1. Purpose

The purpose of this Business Continuity Policy is to establish a framework for maintaining and recovering critical business operations in the event of a disruption. The goal is to minimize the impact of incidents, ensure continuity of essential services, and safeguard the interests of customers, employees, and stakeholders.

2. Scope

This Policy applies to all departments, employees, and third parties engaged with Kingfield Software business operations. It covers all information systems, data centers, facilities, and functions necessary for delivering critical products and services.

3. Objectives

  • Ensure the safety of employees and visitors during any incident.
  • Maintain continuity of critical operations and services.
  • Minimize financial, operational, and reputational impacts from disruptions.
  • Establish clear recovery priorities and timelines.
  • Comply with legal, regulatory, and contractual continuity requirements.

4. Roles and Responsibilities

  • Executive Management: Provides strategic oversight, ensures adequate resources for continuity planning, and approves the Business Continuity Plan (BCP).
  • Business Continuity Manager: Develops, maintains, and tests the BCP; coordinates training and exercises.
  • Department Heads: Identify critical processes, maintain department recovery plans, and ensure staff awareness.
  • IT Department: Implements and maintains IT disaster recovery capabilities for systems supporting critical business processes.
  • Employees: Understand their roles during incidents and comply with business continuity procedures.

5. Business Impact Analysis (BIA)

The Company shall conduct a Business Impact Analysis to identify critical processes, dependencies, recovery time objectives (RTOs), and recovery point objectives (RPOs). The BIA informs the prioritization of recovery efforts and resource allocation.

6. Risk Assessment

A periodic risk assessment will be performed to identify threats that could disrupt operations, including natural disasters, cyberattacks, utility failures, and supply chain disruptions. Mitigation strategies will be implemented based on assessed risks.

7. Business Continuity Planning

The Company will maintain a documented Business Continuity Plan (BCP) that outlines procedures for responding to, managing, and recovering from disruptions. The plan shall include emergency contact lists, recovery teams, alternate work arrangements, and communication strategies.

8. IT Disaster Recovery

The IT Department shall maintain a Disaster Recovery Plan (DRP) to ensure restoration of critical systems and data. Regular backups must be conducted, tested, and stored securely in accordance with the Company’s Data Backup Policy.

9. Testing and Exercises

Business continuity and disaster recovery plans must be tested at least annually. Tests may include tabletop exercises, simulation drills, or full-scale recovery tests. Lessons learned from these exercises will be documented and incorporated into plan updates.

10. Communication and Awareness

All employees shall be made aware of the Business Continuity Policy and their respective responsibilities. Crisis communication protocols will be established to ensure clear, timely, and accurate communication with stakeholders during incidents.

11. Plan Maintenance and Review

This Policy and associated plans will be reviewed annually or following significant organizational, technological, or operational changes. Updates shall be approved by Executive Management and distributed to relevant stakeholders.

12. Compliance and Audit

Compliance with this Policy will be verified through periodic audits. Findings and corrective actions will be documented and tracked to ensure continual improvement in business continuity readiness.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: +1 (651) 398-7580

Data Destruction and Retention Policy

Effective Date: October 29, 2025
Applies To: All data, systems, and personnel of Kingfield Software.

1. Purpose

This Policy establishes Kingfield Software's rules for retaining and securely destroying data to meet legal, regulatory, and contractual obligations, reduce risk, and protect the confidentiality, integrity, and availability of information. It defines minimum retention periods, approved destruction methods, and the roles responsible for oversight and execution.

2. Scope

This Policy applies to all information created, received, processed, or stored by the Company, regardless of format (electronic, paper, physical media), including production systems, backups, logs, collaboration tools, and third-party/SaaS platforms. It covers employees, contractors, and service providers.

3. Definitions

  • Personal Data: Information relating to an identified or identifiable individual.
  • Record: Information created, received, and maintained as evidence of business activities.
  • Retention Period: The minimum time a record must be kept before destruction.
  • Destruction: Rendering data unreadable, indecipherable, and irrecoverable.

4. Roles and Responsibilities

  • Information Security Officer (ISO): Maintains this Policy; ensures controls exist for secure storage, retention, and destruction.
  • Data Owners: Define retention needs for their domains; approve destruction of records at end-of-life.
  • Legal/Compliance: Defines legal holds; validates retention with laws, regulations, and contracts.
  • IT / DevOps: Implements technical controls; manages backups and destruction workflows; maintains logs of destruction and access.
  • Vendors/Processors: Follow this Policy or equivalent; provide Certificates of Destruction when disposing of Company data.
  • Employees: Handle data per classification and retention schedule; report issues or suspected policy violations.

5. Data Classification

Retention and destruction requirements are aligned to the Company’s Data Classification & Handling Policy. At minimum, data is classified into:

  • Public: Intended for public disclosure.
  • Internal: Non-public operational information.
  • Confidential: Business-sensitive data; limited to need-to-know access.
  • Restricted: Highly sensitive data (e.g., secrets, credentials, regulated personal data).

6. Retention Schedule (Summary)

The following table provides baseline retention periods. System- or jurisdiction-specific requirements may override these baselines; see departmental procedures and legal guidance for details.

7. Legal and Regulatory Requirements

Retention periods must comply with applicable laws, regulations, standards, and contracts (e.g., tax, employment, privacy, and industry-specific rules). When requirements conflict, the stricter requirement applies.

8. Storage, Backups, and Archiving

Backups must be encrypted and follow documented retention schedules (e.g., daily/weekly/monthly rotations). Backup copies inherit the retention of their source data. Destruction of expired data must include destruction of all associated backup copies by schedule, except where prohibited by legal hold.

9. Destruction Methods

Approved destruction methods by media type include:

  • Electronic media (HDD/SSD, tapes, removable media): cryptographic erase, secure wipe, or physical destruction by certified vendor.
  • Cloud storage/virtual volumes: provider-supported secure deletion, crypto key destruction, and verification via API logs or certificates.
  • Paper records: cross-cut shredding, pulping, or incineration via certified vendor.
  • Portable devices: factory reset plus MDM wipe and verification; remove from inventory after proof of wipe.

10. Authorization, Verification, and Evidence

Destruction of data reaching end-of-life must be authorized by the Data Owner (and Legal when required). All destruction events must be logged and, when handled by vendors, accompanied by a Certificate of Destruction. Verification may include spot checks, hash comparisons, or storage inventory reconciliation.

11. Legal Holds and Suspensions

When Legal issues a litigation hold or regulatory suspension, destruction of affected records and backups is paused. Holds remain until Legal provides written release. Departments are responsible for preserving relevant records.

12. Data Subject and Customer Requests

Requests to delete or export personal data (e.g., under GDPR/CCPA) are processed per the Company’s Privacy Program. Deletion is performed unless retention is required by law or contract; conflicts are escalated to Legal/Compliance.

13. Third-Party Processors

Vendors handling Company data must implement equivalent retention and destruction controls and provide attestations or Certificates of Destruction upon request. Contracts must include data return/erasure clauses at termination.

14. Training and Awareness

Employees receive training on data classification, retention, and destruction procedures as part of onboarding and annually thereafter.

15. Exceptions

Exceptions to this Policy require documented approval from the ISO and Legal/Compliance, including justification, scope, and duration.

16. Review and Maintenance

This Policy is reviewed at least annually or upon significant organizational or regulatory changes. Updates are approved by Executive Management and communicated to stakeholders.

17. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Record CategoryExamplesMinimum RetentionDisposition
Customer Contracts & OrdersMSA/SOW, order forms, amendments7 years after termination/expirationSecure destruction after retention; retain if under legal hold
Financial & TaxGeneral ledger, invoices, payroll, tax filings7 years (or as required by law)Secure destruction after retention
HR & EmploymentPersonnel files, I-9, performance records3–7 years after termination (see local law)Secure destruction after retention
Security & Audit LogsApp/infra logs, access logs, SIEM exports12–24 months (per risk/regulatory)Secure destruction after retention
Product & Source CodeRepos, build artifacts, release recordsIndefinite while product supported; 3 years after EOLSecure archive or destruction
Customer Support RecordsTickets, chat transcripts2–3 yearsSecure destruction after retention
BackupsFull/incremental backups, snapshotsPer backup schedule; see Section 8Media reuse only after verified sanitation
Data Security Policy

Effective Date: October 29, 2025
Applies To: All data, systems, and employees of Kingfield Software.

1. Purpose

The purpose of this Data Security Policy is to establish Kingfield Software’s principles, responsibilities, and controls for safeguarding company and customer data. This Policy defines security measures to protect the confidentiality, integrity, and availability of data across all systems and environments.

2. Scope

This Policy applies to all employees, contractors, and third parties who access or manage company data and systems. It includes all data types—electronic, paper, or cloud-based—stored, processed, or transmitted within corporate or hosted environments.

3. Objectives

  • Protect information assets against unauthorized access, modification, loss, or disclosure.
  • Ensure compliance with legal, regulatory, and contractual data security obligations.
  • Maintain reliable and secure IT infrastructure through defined controls and procedures.
  • Support incident prevention, detection, and response processes.

4. Roles and Responsibilities

  • Information Security Officer (ISO): Oversees implementation of security controls, monitors compliance, and manages incident response.
  • IT / DevOps Team: Implements and maintains security configurations, access controls, and monitoring systems.
  • Department Heads: Ensure adherence to this Policy and report any suspected security issues.
  • Employees: Follow security guidelines, report suspicious activity, and safeguard credentials and devices.
  • Third-Party Vendors: Maintain equivalent security standards and comply with contractual data protection requirements.

5. Data Classification and Handling

All data must be classified and handled according to the Company’s Data Classification & Handling Policy. Data is categorized as Public, Internal, Confidential, or Restricted. Security measures, access levels, and storage requirements are determined based on classification level.

6. Access Control

Access to systems and data is granted based on the principle of least privilege. Multi-factor authentication (MFA) is required for privileged accounts and remote access. User access rights are reviewed quarterly, and accounts of terminated users are promptly disabled.

7. Data Encryption

All sensitive data must be encrypted both in transit and at rest. Encryption keys are managed securely using industry-standard key management solutions (e.g., AWS KMS).

8. Network Security

Network boundaries are protected with firewalls, intrusion detection/prevention systems (IDS/IPS), and regular vulnerability scans. Wireless networks must use strong encryption (e.g., WPA2 or higher) and unique credentials.

9. Endpoint Security

All company-managed endpoints (laptops, servers, mobile devices) must be configured with endpoint protection software, automatic patching, and full-disk encryption. Personal devices accessing company data must comply with Bring Your Own Device (BYOD) standards.

10. Data Backup and Recovery

Critical data is backed up regularly and stored securely in encrypted form. Backup data is tested periodically to verify integrity and recovery capability.

11. Logging and Monitoring

System and application logs must be retained for at least 12 months. Logs are monitored for anomalies, and alerts are configured for suspicious activity. Security Information and Event Management (SIEM) systems are used to aggregate and analyze security events.

12. Incident Response

Security incidents must be reported immediately to the ISO. The Incident Response Plan defines steps for containment, eradication, recovery, and post-incident review.

13. Data Disposal

Data and media no longer required must be securely destroyed according to the Data Destruction and Retention Policy. Methods include cryptographic wipe, secure erase, and physical destruction by certified vendors.

14. Vendor and Third-Party Security

Vendors with access to company systems or data must undergo security assessments and maintain contractual obligations for data protection. Vendor compliance is reviewed periodically.

15. Security Awareness and Training

All employees receive security training during onboarding and annually thereafter. Awareness campaigns reinforce phishing prevention, password hygiene, and incident reporting.

16. Compliance and Audit

The Company will periodically audit adherence to this Policy and applicable security frameworks (e.g., ISO 27001, SOC 2, NIST). Findings will be remediated through the risk management process.

17. Policy Review and Maintenance

This Policy is reviewed annually or upon significant organizational, technological, or regulatory changes. Updates are approved by Executive Management and communicated to all relevant parties.

18. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Disaster Recovery Policy

Effective Date: October 29, 2025
Applies To: All systems, applications, and personnel of Kingfield Software.

1. Purpose

The purpose of this Disaster Recovery Policy is to define Kingfield Software’s framework for recovering IT systems, data, and operations following a disaster or major disruption. This policy ensures timely restoration of critical business functions to minimize downtime and data loss.

2. Scope

This Policy applies to all information systems, infrastructure, applications, and cloud environments owned or managed by the Company. It includes production systems, backups, and supporting technology services necessary for business continuity.

3. Objectives

  • Define a structured process for disaster recovery and system restoration.
  • Minimize operational and financial impact from disasters.
  • Ensure data integrity and availability during recovery operations.
  • Support compliance with applicable legal, regulatory, and contractual obligations.

4. Roles and Responsibilities

  • Executive Management: Approves recovery strategies and allocates resources for disaster recovery activities.
  • Information Security Officer (ISO): Oversees disaster recovery preparedness, plan updates, and testing.
  • IT / DevOps Team: Implements and maintains disaster recovery mechanisms, backup systems, and failover environments.
  • Department Heads: Identify critical business processes and ensure staff understand their recovery responsibilities.
  • Employees: Follow recovery procedures and report any system outages or incidents immediately.

5. Disaster Recovery Strategy

The Company’s disaster recovery strategy focuses on restoring critical systems and data based on defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Key components include redundant infrastructure, automated backups, high availability configurations, and tested recovery procedures.

6. Recovery Objectives

Each critical system shall have defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). RTO defines the maximum acceptable downtime; RPO defines the maximum acceptable data loss measured in time.

Typical baseline targets: • Critical systems: RTO = 4 hours, RPO = 1 hour • Important systems: RTO = 24 hours, RPO = 12 hours • Non-critical systems: RTO = 72 hours, RPO = 24 hours

7. Backup and Replication

All critical data and configurations must be backed up on a defined schedule. Backups are encrypted and stored in geographically separate locations. Replication technologies may be used to ensure near real-time availability of data for mission-critical systems.

8. Disaster Recovery Procedures

The Disaster Recovery Plan (DRP) outlines step-by-step procedures for detecting, declaring, and responding to disasters. Procedures include activation of the recovery team, communication protocols, system restoration, and validation of restored services.

9. Communication and Escalation

During a disaster event, communication is coordinated by the Disaster Recovery Lead. Internal and external stakeholders are notified per the Crisis Communication Plan. Escalation paths and contact lists are maintained and tested regularly.

10. Testing and Exercises

The Company conducts annual disaster recovery tests, including tabletop exercises, partial failovers, and full-scale recovery drills. Test results are documented, and remediation actions are tracked to improve recovery capabilities.

11. Plan Maintenance and Review

The Disaster Recovery Plan is reviewed at least annually, after significant infrastructure or business changes, or following an actual disaster event. Updates are approved by Executive Management and distributed to all relevant personnel.

12. Third-Party and Cloud Provider Responsibilities

Third-party and cloud providers that support critical business operations must maintain equivalent disaster recovery capabilities. Service-level agreements (SLAs) must specify recovery objectives and responsibilities for continuity and restoration.

13. Compliance and Audit

The Company ensures compliance with industry standards and regulations related to disaster recovery and continuity (e.g., ISO 27001, SOC 2, NIST SP 800-34). Regular audits verify adherence to this Policy and the Disaster Recovery Plan.

14. Training and Awareness

All personnel involved in recovery activities receive annual training on disaster recovery procedures and responsibilities. Awareness sessions promote preparedness and reinforce best practices for minimizing impact during disruptions.

15. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Email Use Policy (Application Email Handling)

Effective Date: October 30, 2025
Applies To: All products, applications, systems, and services operated by Kingfield Software that send, receive, or process email.

1. Purpose

The purpose of this Email Use Policy is to define how Kingfield Software applications handle email communications sent through or generated by its systems. This policy ensures that all outbound and inbound email functions comply with security, privacy, and regulatory standards, while maintaining user trust and minimizing abuse.

2. Scope

This Policy applies to all company-managed applications, APIs, and services that facilitate email delivery, including transactional, system-generated, and marketing messages. It also governs the handling of incoming email replies, bounce messages, and user responses where applicable.

3. Principles

  • Emails are sent only with valid authorization and business justification.
  • Recipients must have provided verifiable consent where applicable (opt-in or account creation).
  • Emails must clearly identify the sender and include appropriate contact information.
  • Recipients must have a simple, functional method to opt out or unsubscribe from non-transactional messages.
  • All email operations must comply with anti-spam and privacy regulations.

4. Types of Email Communications

Kingfield Software applications may generate or process the following categories of email:

  • Transactional Emails – e.g., password resets, account verifications, system alerts, invoices.
  • Operational Emails – e.g., maintenance notices, policy updates, or system performance communications.
  • Marketing and Informational Emails – e.g., newsletters, product announcements, promotional messages (sent only to consenting recipients).
  • Support or Workflow Emails – e.g., responses to help desk tickets or workflow automation notifications.

5. Email Sending Practices

All outbound email transmissions from company-managed systems must comply with industry best practices, including authentication and anti-abuse measures.

  • All sending domains must be configured with SPF, DKIM, and DMARC records.
  • Email content must not include malicious links, scripts, or attachments.
  • Rate limiting, reputation monitoring, and bounce handling must be implemented for all bulk or automated mail systems.
  • Emails must originate from verified company domains or authorized third-party mail services.
  • Automated systems must use dedicated sender addresses that are monitored or clearly identified as ‘no-reply’.

6. Customer and User Responsibilities

  • Customers using Kingfield Software applications to send email must ensure their content and recipient lists comply with applicable regulations (e.g., CAN-SPAM, GDPR, CASL).
  • Users may not use Kingfield Software systems to send unsolicited bulk or commercial email (‘spam’).
  • Customers must maintain accurate sender information and promptly honor unsubscribe or suppression list requests.
  • Email-sending APIs and integrations must include proper authentication and authorization mechanisms.

7. Data Privacy and Security

Email data—including content, metadata, and recipient addresses—is handled as confidential information. All systems transmitting or storing email data must use encryption in transit (TLS) and at rest. Access to email logs, queues, and related data is restricted to authorized personnel only.

8. Retention and Logging

Email logs and delivery records are retained only as long as necessary to support operational, security, and compliance requirements. Retention periods must align with the Company’s Data Destruction and Retention Policy. All logs containing email addresses or content must be protected against unauthorized access.

9. Monitoring and Abuse Prevention

Kingfield Software actively monitors its email delivery systems for abuse, phishing, or unauthorized sending behavior. Suspicious or non-compliant activity may result in account suspension or termination. The Company reserves the right to block or throttle email sending to preserve system integrity and reputation.

10. Compliance

All email communications must comply with applicable laws and standards, including (but not limited to):

  • CAN-SPAM Act (United States)
  • General Data Protection Regulation (GDPR, EU)
  • Canada’s Anti-Spam Legislation (CASL)
  • Other local privacy or anti-spam laws in regions of operation

11. Incident Response

In the event of a security breach, unauthorized access, or suspected misuse of email systems, the Incident Response Plan will be activated. Incidents must be reported immediately to the Information Security Officer or through established support channels.

12. Policy Review and Maintenance

This Policy is reviewed annually or when significant technical, regulatory, or operational changes occur. Updates are approved by executive management and communicated to affected stakeholders.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Encryption Policy

Effective Date: October 30, 2025
Applies To: All systems, applications, and data managed by Kingfield Software.

1. Purpose

The purpose of this Encryption Policy is to establish requirements for the use of encryption to protect the confidentiality and integrity of data managed, transmitted, or stored by Kingfield Software. Encryption ensures that sensitive information remains secure from unauthorized disclosure or alteration.

2. Scope

This Policy applies to all information systems, applications, and data handled by the Company, including data in transit and data at rest. It applies to employees, contractors, vendors, and any third parties who access or store Company data.

3. Objectives

  • Ensure appropriate encryption methods are used for protecting sensitive and regulated information.
  • Define standards for key management and cryptographic implementation.
  • Support compliance with applicable legal and regulatory requirements (e.g., GDPR, HIPAA, PCI DSS).
  • Reduce the risk of data breaches or exposure through encryption failures.

4. Data Classification and Encryption Requirements

Encryption requirements are determined based on the data’s classification level, following the Company’s Data Classification & Handling Policy:

  • Restricted Data: Must be encrypted both at rest and in transit using approved algorithms (e.g., AES-256, TLS 1.2+).
  • Confidential Data: Must be encrypted in transit and should be encrypted at rest when feasible.
  • Internal Data: Encryption is recommended in transit; at-rest encryption is at the discretion of system owners.
  • Public Data: Encryption is optional but encouraged for integrity protection.

5. Encryption Standards

All cryptographic implementations must adhere to the following standards:

  • Symmetric Encryption: AES-128 or stronger (preferred: AES-256).
  • Asymmetric Encryption: RSA 2048-bit or ECC P-256 or stronger.
  • Hashing: SHA-256 or stronger for integrity checks (MD5 and SHA-1 are prohibited).
  • Transport Encryption: TLS 1.2 or higher for all network communications containing sensitive data.
  • Email Encryption: Use S/MIME, TLS, or equivalent secure methods for transmitting sensitive content.

6. Key Management

Encryption keys must be generated, distributed, stored, rotated, and destroyed according to secure key management principles. Keys must not be hard-coded into applications or stored in plaintext. Approved key management systems (e.g., AWS KMS, Azure Key Vault) must be used.

  • Keys must be rotated at least annually or immediately following a suspected compromise.
  • Access to encryption keys must be limited to authorized personnel on a need-to-know basis.
  • Key backups must be encrypted and stored separately from the data they protect.
  • Encryption keys must not be transmitted through unsecured channels such as email or chat.

7. Data in Transit

All sensitive or confidential data transmitted over public or untrusted networks must be encrypted using TLS 1.2+ or an equivalent secure protocol. Legacy or insecure protocols (e.g., FTP, Telnet, HTTP, SSLv3) must not be used.

8. Data at Rest

Data stored on servers, databases, endpoints, removable media, or cloud storage must be encrypted using industry-standard algorithms (AES-256 or stronger). Disk-level encryption and database encryption mechanisms should be implemented where supported.

9. Cloud Services and Third Parties

All third-party and cloud service providers storing or processing Company data must implement encryption controls consistent with this Policy. Service agreements must specify encryption responsibilities and compliance requirements.

10. Key Escrow and Recovery

Where key escrow or recovery is required, it must be implemented securely using approved mechanisms. Recovery processes must ensure only authorized personnel can retrieve encryption keys or decrypt data.

11. Compliance and Audit

Compliance with this Policy is verified through periodic reviews and audits. Audit results must be documented, and any deviations or weaknesses must be remediated promptly.

12. Policy Review and Maintenance

This Policy is reviewed annually or when significant changes to cryptographic standards, technologies, or regulations occur. Updates must be approved by executive management and communicated to relevant stakeholders.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Exception Request Policy

Effective Date: October 30, 2025
Applies To: All departments, employees, contractors, and third parties within Kingfield Software requesting exceptions to established security or operational policies.

1. Purpose

The purpose of this Exception Request Policy is to define a formal process for requesting, reviewing, approving, and documenting exceptions to Kingfield Software’s established policies, standards, and procedures. This ensures exceptions are granted only when justified, risk is assessed, and compensating controls are implemented where necessary.

2. Scope

This Policy applies to all employees, contractors, business units, and third parties seeking exceptions to Company policies or standards, including security controls, compliance requirements, or operational practices.

3. Definition

An exception is a documented and approved deviation from an established Company policy, standard, or procedure. Exceptions may be temporary or permanent, depending on the circumstances and risk exposure.

4. Guiding Principles

  • Exceptions must be documented, justified, and time-bound.
  • All exceptions must undergo a risk assessment to identify potential business and security impacts.
  • Compensating controls must be defined to mitigate identified risks where possible.
  • Exceptions are not automatically renewed and must be re-evaluated upon expiration.
  • Approvals must be obtained before the exception is implemented.

5. Exception Request Process

  • 1. **Submission** – The requester completes an Exception Request Form, including a detailed description, rationale, scope, affected systems, and duration.
  • 2. **Risk Assessment** – The Information Security Officer (ISO) or delegate evaluates associated risks, potential impact, and required compensating controls.
  • 3. **Review and Approval** – Requests are reviewed by management and approved by the ISO and Executive Management, as applicable.
  • 4. **Documentation** – All approved exceptions are recorded in the Exception Register, including expiration dates and review schedules.
  • 5. **Implementation and Monitoring** – The requester implements compensating controls and ensures adherence to any conditions of approval.
  • 6. **Periodic Review** – Exceptions are reviewed at least annually or upon significant change to ensure continued validity and necessity.

6. Risk Assessment

Each exception request must include a documented risk assessment outlining the following:

  • Potential threats or vulnerabilities introduced by the exception.
  • Business justification and potential operational impact of denial.
  • Proposed compensating controls or mitigation measures.
  • Estimated duration and planned remediation or compliance date.

7. Approval Authorities

Approvals are based on the level of risk and potential business impact:

  • Low Risk – Department Manager and Information Security Officer.
  • Medium Risk – Information Security Officer and Executive Management.
  • High Risk – Executive Management and, if applicable, the Board of Directors.

8. Documentation and Recordkeeping

All exception requests, reviews, approvals, and renewals must be documented and retained for a minimum of three years. The Exception Register must include requester details, approval signatures, risk level, and expiration date.

9. Expiration and Renewal

Each exception must have a defined expiration date. Renewal requires a new review and approval cycle. Expired exceptions must either be closed or revalidated with justification and risk reassessment.

10. Monitoring and Compliance

The Information Security Officer is responsible for monitoring exception requests and compliance with this Policy. Internal audits may review exception documentation to ensure proper control and governance.

11. Policy Review and Maintenance

This Policy will be reviewed annually or upon major organizational, operational, or regulatory changes. Updates must be approved by Executive Management and communicated to all relevant parties.

12. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Incident Management Policy

Effective Date: October 30, 2025
Applies To: All employees, contractors, and third parties of Kingfield Software who manage, monitor, or have access to information systems and data.

1. Purpose

The purpose of this Information Security Incident Management Policy is to ensure a consistent, effective, and timely approach to identifying, reporting, and managing information security incidents within Kingfield Software. This policy establishes procedures to minimize the impact of incidents, preserve evidence, and support compliance with legal and regulatory obligations.

2. Scope

This Policy applies to all {company_name} personnel, systems, applications, and networks that store, process, or transmit Company or customer data. It includes all incidents involving unauthorized access, disclosure, modification, destruction, or loss of information assets.

3. Definitions

  • Information Security Incident – Any event that compromises or has the potential to compromise the confidentiality, integrity, or availability of information or systems.
  • Security Event – An observable occurrence within a system or network that may indicate an incident or abnormal behavior.
  • Incident Response Team (IRT) – A designated group responsible for coordinating and executing incident response activities.

4. Objectives

  • Detect and respond to information security incidents in a timely and consistent manner.
  • Minimize disruption to business operations and data integrity.
  • Ensure effective communication and escalation during incidents.
  • Preserve evidence for legal, regulatory, or forensic purposes.
  • Facilitate continuous improvement through post-incident analysis.

5. Roles and Responsibilities

  • Information Security Officer (ISO): Leads the incident response process, oversees investigations, and ensures appropriate reporting and remediation.
  • Incident Response Team (IRT): Coordinates containment, eradication, recovery, and documentation activities.
  • IT / DevOps Teams: Assist in identifying root causes, isolating affected systems, and restoring normal operations.
  • Department Managers: Ensure personnel report incidents promptly and cooperate during investigations.
  • All Employees and Contractors: Report suspected or actual security incidents immediately through designated channels.

6. Incident Classification

Incidents are classified based on their severity and potential business impact to guide appropriate response actions:

  • Low – Minor issue with minimal impact and easily contained (e.g., failed login attempts).
  • Medium – Localized impact requiring containment and possible user or system recovery (e.g., malware infection).
  • High – Significant data exposure or system compromise requiring executive notification and external reporting (e.g., data breach, ransomware).

7. Incident Reporting

All employees, contractors, and third parties must report actual or suspected security incidents immediately to the Information Security Officer or the IT Helpdesk. Reports should include details such as the nature of the incident, affected systems, and observed impact.

8. Incident Response Process

  • 1. Identification – Detect and validate potential incidents through monitoring, alerts, or user reports.
  • 2. Containment – Limit the scope and spread of the incident while maintaining critical operations.
  • 3. Eradication – Remove malicious code, close vulnerabilities, and verify system integrity.
  • 4. Recovery – Restore systems, services, and data to normal operation with verified integrity.
  • 5. Notification – Communicate with affected parties, regulators, or customers as required by law or contract.
  • 6. Lessons Learned – Conduct a post-incident review to identify root causes and improve controls.

9. Evidence Preservation

During incident handling, all relevant data, logs, and system artifacts must be preserved for investigation and potential legal proceedings. Only authorized personnel may handle evidence, following documented chain-of-custody procedures.

10. Communication and Escalation

Incident communication must follow the Company’s escalation plan. Only authorized personnel may communicate with external parties, including customers, regulators, and media. Sensitive information about ongoing investigations must be shared strictly on a need-to-know basis.

11. External Notifications

If an incident involves the compromise of personal or customer data, notifications will be made in accordance with applicable data protection laws and contractual requirements. The Information Security Officer coordinates all external communications and regulatory filings.

12. Post-Incident Review

After each incident, a formal review must be conducted to evaluate the effectiveness of detection, response, and communication processes. Findings must be documented, and corrective actions tracked to completion.

13. Training and Awareness

All employees and contractors must receive incident response training during onboarding and periodic refresher courses. Awareness activities reinforce timely reporting and the importance of maintaining vigilance.

14. Policy Review and Maintenance

This Policy is reviewed annually or following significant changes in the threat landscape, technology, or business operations. Updates must be approved by Executive Management and communicated to all relevant stakeholders.

15. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Internet Security Policy

Effective Date: October 30, 2025
Applies To: All network infrastructure, systems, and services within Kingfield Software that provide or rely on internet connectivity.

1. Purpose

The purpose of this Internet Security Policy is to establish controls that protect Kingfield Software’s information systems from threats originating from the internet. The policy defines measures to prevent unauthorized access, ensure confidentiality and integrity of transmitted data, and maintain availability of online services.

2. Scope

This Policy applies to all Company-managed network infrastructure, cloud environments, applications, and endpoints that transmit or receive data over the internet. It includes firewalls, routers, VPNs, web gateways, and any internet-facing systems or APIs.

3. Objectives

  • Protect corporate networks and systems from unauthorized access and malicious activity.
  • Ensure secure configuration and management of internet-facing assets.
  • Detect, respond to, and prevent cyberattacks and data breaches.
  • Maintain compliance with applicable security and privacy regulations.
  • Provide a consistent framework for monitoring and maintaining internet security posture.

4. Internet Connectivity Controls

All internet access points must be secured and approved by the Information Security Officer (ISO). The following requirements apply to all internet-connected systems:

  • Use of firewalls to restrict inbound and outbound network traffic to authorized ports, protocols, and IP addresses.
  • Implementation of intrusion detection and prevention systems (IDS/IPS) to monitor and block malicious activity.
  • Segregation of public-facing systems from internal networks using demilitarized zones (DMZs).
  • Regular vulnerability scanning and penetration testing of internet-facing assets.
  • Use of secure DNS services with domain filtering and logging to prevent access to known malicious domains.

5. Firewall and Network Configuration

  • Firewalls must be configured according to the principle of least privilege, allowing only required services.
  • All configuration changes must be documented, reviewed, and approved by authorized personnel.
  • Firewall rule sets must be reviewed at least quarterly to ensure continued relevance and compliance.
  • Default-deny policies must be enforced for inbound internet traffic.
  • Administrative access to network devices must use secure management protocols (e.g., SSH, HTTPS).

6. Internet-Facing Systems

  • All web servers, APIs, and public applications must be protected by web application firewalls (WAFs) where applicable.
  • Systems must be hardened following industry best practices, including disabling unused ports, services, and accounts.
  • TLS 1.2 or higher must be used for all web-based connections.
  • Certificates must be valid, managed centrally, and renewed before expiration.
  • Regular security patching and vulnerability management must be enforced on all internet-facing systems.

7. Remote Access Security

  • All remote access to corporate systems must use VPN or equivalent secure tunneling technologies.
  • Multi-factor authentication (MFA) must be required for all remote logins.
  • Remote connections must be encrypted and logged for monitoring and audit purposes.
  • Access must be restricted to authorized personnel and reviewed periodically.

8. Internet Monitoring and Logging

All internet traffic must be monitored for malicious activity, bandwidth misuse, or policy violations. Logs must be retained for at least 12 months or longer as required by regulation.

  • Network security monitoring systems (e.g., SIEM) must aggregate and correlate internet traffic logs.
  • Alerts for suspicious traffic patterns, data exfiltration, or intrusion attempts must be configured and reviewed regularly.
  • Automated blocking or throttling mechanisms must be employed to contain attacks such as DDoS or brute-force attempts.
  • Logs must include timestamps, source/destination IPs, protocols, and actions taken.

9. Cloud and Third-Party Internet Services

All third-party or cloud-hosted services that connect to or operate over the internet must adhere to equivalent security standards as this Policy. Vendor risk assessments must be completed before enabling integrations or data transfers.

  • All data transmissions to or from third parties must use secure protocols (e.g., HTTPS, SFTP, TLS).
  • Service-level agreements (SLAs) must define security responsibilities and incident notification requirements.
  • Cloud access must be managed through identity and access management (IAM) policies and MFA enforcement.

10. Security Testing and Vulnerability Management

  • Regular vulnerability scans must be conducted for all internet-facing systems.
  • Penetration tests must be performed at least annually and after major infrastructure changes.
  • Identified vulnerabilities must be remediated based on severity following the Company’s Risk Management Policy.
  • Findings and remediation efforts must be documented and reviewed by the Information Security Officer.

11. Incident Response

Any detected or suspected internet-based attack must be reported and managed according to the Information Security Incident Management Policy. Incident response procedures must include containment, eradication, and recovery steps, along with notification to affected stakeholders.

12. Policy Review and Maintenance

This Policy is reviewed annually or following significant network, technology, or threat landscape changes. Revisions must be approved by Executive Management and communicated to all relevant stakeholders.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Mobile Device Policy

Effective Date: October 30, 2025
Applies To: All software applications, systems, and development teams at Kingfield Software responsible for building, testing, and maintaining mobile-friendly products.

1. Purpose

The purpose of this Mobile Device Policy is to establish best practices and compliance requirements to ensure that all Kingfield Software software applications are secure, efficient, and user-friendly on mobile devices. This policy guides design, development, and testing processes to promote accessibility, performance, and security across all supported mobile platforms.

2. Scope

This Policy applies to all software products, APIs, and services developed or managed by the Company that are accessed via mobile devices, including web applications, native applications, and responsive interfaces. It encompasses all mobile operating systems and browsers officially supported by the Company.

3. Objectives

  • Ensure consistent and secure user experiences across all mobile devices and platforms.
  • Promote adherence to recognized mobile design, security, and accessibility standards.
  • Reduce security and usability risks associated with mobile device constraints.
  • Maintain compatibility with major mobile operating systems and browser versions.
  • Enhance customer satisfaction through responsive and reliable application performance.

4. Mobile Compatibility Standards

All applications must be designed and tested to comply with modern mobile standards and usability principles, including:

  • Responsive design using fluid layouts, flexible media, and adaptive typography.
  • Cross-platform compatibility testing for iOS and Android devices, covering current and previous major OS versions.
  • Adherence to platform-specific guidelines such as Apple’s Human Interface Guidelines and Google’s Material Design.
  • Support for accessibility features, including screen readers, high-contrast modes, and large-text scaling.
  • Regular validation of rendering, performance, and interaction across supported browsers and device types.

5. Performance Optimization

Applications must be optimized to minimize bandwidth usage, improve load times, and ensure reliable operation under varying network conditions:

  • Use caching, compression, and lazy loading to enhance responsiveness.
  • Minimize HTTP requests and resource sizes for faster mobile performance.
  • Ensure APIs are efficient and optimized for mobile consumption.
  • Conduct periodic mobile performance benchmarks and load testing.

6. Security and Data Protection

Mobile applications must incorporate security controls that safeguard data in transit and at rest while maintaining compliance with relevant privacy regulations:

  • Use HTTPS/TLS 1.2 or higher for all mobile communications.
  • Implement local encryption for sensitive data stored on mobile devices.
  • Avoid storing credentials or tokens in plaintext or unsecured device storage.
  • Validate input on both client and server to prevent injection or manipulation attacks.
  • Follow least-privilege principles when requesting mobile app permissions (e.g., location, camera, storage).

7. Testing and Quality Assurance

All mobile-accessible applications must undergo comprehensive testing to verify functionality, usability, and compliance with security and design standards:

  • Conduct usability testing on representative mobile devices and screen sizes.
  • Perform mobile security testing to identify vulnerabilities and ensure compliance with OWASP Mobile Security Testing Guide (MSTG).
  • Validate responsive layout and accessibility compliance (WCAG 2.1 or later).
  • Document all test results and remediation actions prior to production deployment.

8. Data Privacy and Regulatory Compliance

All mobile applications must comply with data protection and privacy regulations applicable to their use cases and target markets, including:

  • General Data Protection Regulation (GDPR) for EU-based users.
  • California Consumer Privacy Act (CCPA) for California residents.
  • Children’s Online Privacy Protection Act (COPPA) where applicable.
  • Other jurisdictional privacy requirements based on end-user location or service scope.

9. Third-Party Libraries and SDKs

All third-party libraries, frameworks, and SDKs used in mobile applications must be approved, tracked, and regularly updated to mitigate security risks:

  • Use only reputable and actively maintained libraries.
  • Review third-party privacy policies and licensing agreements before integration.
  • Monitor vulnerability databases (e.g., NVD, GitHub advisories) for known issues.
  • Promptly patch or replace components found to have security vulnerabilities.

10. Continuous Improvement and Review

The Company commits to continuous improvement in mobile application development and compliance through regular reviews, testing, and feedback collection. Mobile standards and requirements will be updated to align with emerging technologies and user expectations.

11. Policy Review and Maintenance

This Policy will be reviewed annually or upon major updates to mobile technology, security standards, or regulatory requirements. Revisions must be approved by Executive Management and communicated to all development teams.

12. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Network Security Policy

Effective Date: October 30, 2025
Applies To: All production and cloud-hosted networks, systems, and environments managed or operated by Kingfield Software.

1. Purpose

The purpose of this Network Security Policy is to establish controls for protecting the integrity, confidentiality, and availability of Kingfield Software’s production application networks. This policy defines requirements for securing network infrastructure, monitoring network traffic, and maintaining compliance with security best practices and industry standards.

2. Scope

This Policy applies to all production environments, virtual private clouds (VPCs), load balancers, gateways, firewalls, and other networking components supporting Kingfield Software applications and services. It includes on-premises and cloud-based infrastructure, internal and external network segments, and third-party interconnections.

3. Objectives

  • Establish and maintain secure production network architecture.
  • Control and monitor network access to prevent unauthorized activity.
  • Ensure all data transmitted across networks is encrypted and protected.
  • Monitor for network anomalies, intrusions, and performance degradation.
  • Comply with applicable regulations and standards (e.g., ISO 27001, SOC 2, NIST).

4. Network Architecture and Segmentation

All production networks must follow a layered architecture that separates environments and restricts data flow between zones:

  • Segregate development, testing, staging, and production environments using distinct network segments.
  • Deploy Demilitarized Zones (DMZs) to isolate internet-facing systems from internal components.
  • Implement network segmentation for sensitive workloads (e.g., databases, authentication systems).
  • Restrict administrative interfaces to secure management networks accessible via VPN or private IPs.

5. Firewalls and Access Control

  • All ingress and egress network traffic must pass through managed firewalls.
  • Default-deny rules must be applied to all inbound traffic except explicitly permitted services.
  • Firewall rules must be reviewed quarterly to ensure continued relevance and compliance.
  • Administrative access to firewall configurations must be limited to authorized personnel only.
  • Network Access Control Lists (ACLs) must enforce least-privilege access principles.

6. Network Monitoring and Intrusion Detection

  • Implement Intrusion Detection and Prevention Systems (IDS/IPS) across critical network segments.
  • Enable centralized logging of network activity and forward logs to a Security Information and Event Management (SIEM) system.
  • Continuously monitor network traffic for anomalous behavior, potential attacks, or policy violations.
  • Automated alerts must be configured for suspicious activities such as port scanning or brute-force attempts.

7. Network Encryption

All data transmitted across production networks must be encrypted using industry-approved standards:

  • Use TLS 1.2 or higher for all application and API communications.
  • Encrypt data in motion using AES-256 or stronger algorithms where applicable.
  • Disable insecure protocols and ciphers (e.g., SSL, TLS 1.0, RC4).
  • Use VPNs or private links for administrative or inter-service communication between environments.

8. Network Device Configuration and Hardening

  • All routers, switches, firewalls, and gateways must be securely configured according to vendor and industry best practices.
  • Disable unnecessary ports, services, and management interfaces on all network devices.
  • Default passwords must be changed prior to deployment and replaced with strong credentials.
  • Configuration backups must be encrypted and stored securely.
  • Network configuration changes must follow the Company’s Change Management Policy.

9. Cloud Network Security

  • Use Virtual Private Clouds (VPCs) or equivalent logical segmentation for all cloud environments.
  • Apply security groups and network ACLs to restrict access between instances and services.
  • Enable flow logs and traffic mirroring for auditing and troubleshooting.
  • Regularly review security group configurations for compliance with least privilege principles.
  • Utilize cloud-native security tools (e.g., AWS GuardDuty, Azure Defender) to detect threats.

10. Vendor and Third-Party Connectivity

  • Third-party connections must be approved by the Information Security Officer prior to activation.
  • All vendor integrations must use secure tunnels, VPNs, or private network peering.
  • Contracts with third parties must specify security responsibilities, monitoring, and incident reporting requirements.
  • Periodic security reviews must be conducted for all vendor network connections.

11. Vulnerability Management and Patching

All network devices, appliances, and virtual systems must be regularly patched and scanned for vulnerabilities:

  • Conduct vulnerability scans on network devices and cloud assets at least quarterly.
  • Apply critical security patches within 30 days of release or sooner if actively exploited.
  • Track vulnerabilities through the Company’s risk management system and document remediation efforts.

12. Incident Response and Logging

All network incidents must be handled in accordance with the Information Security Incident Management Policy. Network and firewall logs must be retained for at least 12 months and reviewed periodically for anomalies.

13. Policy Review and Maintenance

This Policy will be reviewed annually or following significant network, cloud infrastructure, or security architecture changes. Updates must be approved by Executive Management and communicated to all relevant stakeholders.

14. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Password Policy

Effective Date: October 30, 2025
Applies To: All customer-facing applications, systems, and services operated by Kingfield Software that require user authentication.

1. Purpose

The purpose of this Password Policy is to define password management requirements for Kingfield Software’s customer-facing applications. This ensures that all user authentication processes protect customer accounts against unauthorized access through secure password creation, storage, and recovery mechanisms.

2. Scope

This Policy applies to all user accounts created, managed, or authenticated through Company applications, APIs, or integrated services. It includes registration, login, password change, recovery, and credential storage functions.

3. Objectives

  • Ensure passwords are created, stored, and transmitted securely.
  • Protect user accounts from credential-based attacks such as brute force and credential stuffing.
  • Support compliance with industry standards (NIST SP 800-63B, OWASP ASVS, ISO 27001).
  • Enable secure, user-friendly authentication practices.

4. Password Creation Requirements

  • Minimum length of 12 characters; users are encouraged to create longer passphrases.
  • Passwords must include a mix of uppercase, lowercase, numbers, and symbols where supported.
  • Common, weak, or previously breached passwords are prohibited (checked against password blacklist or breach databases).
  • Passwords must not contain easily guessable information such as usernames or company names.
  • Password input fields must support visibility toggling and validation feedback to assist users securely.

5. Password Storage

All passwords must be stored using strong, irreversible, salted hash algorithms.

  • Use of PBKDF2, bcrypt, scrypt, or Argon2 for password hashing.
  • Salts must be unique per user and generated using a cryptographically secure random function.
  • Plaintext passwords must never be logged, transmitted, or stored in any system.
  • Password hashes must not be shared between environments or systems.

6. Password Transmission

Passwords must be transmitted securely during login, password reset, or registration processes:

  • All authentication endpoints must use HTTPS/TLS 1.2 or higher.
  • Password-related APIs must not accept credentials over insecure channels (HTTP).
  • Tokens used for password resets must be unique, single-use, and expire within a short period (e.g., 1 hour).

7. Account Lockout and Throttling

  • Login attempts must be rate-limited to mitigate brute-force and credential-stuffing attacks.
  • Accounts must be temporarily locked after a defined number of failed login attempts (e.g., 5).
  • Lockout durations must balance security with usability to minimize denial-of-service risk.
  • All lockout and authentication failure events must be logged for analysis.

8. Multi-Factor Authentication (MFA)

Applications supporting sensitive or financial operations must implement multi-factor authentication (MFA):

  • Support at least one secondary authentication factor such as TOTP, SMS, or hardware-based tokens (e.g., FIDO2).
  • MFA enrollment and recovery processes must include verification of user identity.
  • Users should be encouraged to enable MFA for additional account protection.

9. Password Expiration and Reuse

Frequent password expiration is discouraged unless evidence of compromise exists. Password reuse must be restricted to ensure credential uniqueness and reduce exposure risk.

  • Users must not reuse their last 5 passwords.
  • Passwords should only be reset upon user request, suspected compromise, or security incidents.
  • Forced password changes must require reauthentication and verification.

10. Password Recovery

Password recovery mechanisms must verify user identity and protect against unauthorized resets:

  • Password reset links must expire after a limited time (no longer than 1 hour).
  • Users must be notified via email or SMS when password changes occur.
  • Knowledge-based authentication (e.g., security questions) must be avoided or supplemented with stronger identity verification.

11. Credential Rotation and API Keys

Applications providing API access or token-based authentication must support secure credential lifecycle management:

  • API keys and access tokens must be revocable and time-limited.
  • Rotations must occur automatically at regular intervals or upon suspected compromise.
  • Tokens must have limited scope and privileges per the principle of least privilege.

12. Compliance and Auditing

Compliance with this Policy is verified through regular audits, vulnerability scans, and penetration tests. Findings are documented, and remediation actions are tracked to closure.

13. Policy Review and Maintenance

This Policy is reviewed annually or following major changes to authentication systems, technology, or regulatory requirements. Updates must be approved by Executive Management and communicated to all relevant teams.

14. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Patch Management Policy

Effective Date: October 30, 2025
Applies To: All software development, staging, and production systems managed by Kingfield Software, including applications, APIs, and supporting infrastructure.

1. Purpose

The purpose of this Patch Management Policy is to establish a structured process for identifying, testing, approving, and deploying patches and updates to Kingfield Software software applications and systems. This ensures that security vulnerabilities are mitigated promptly, feature updates are implemented safely, and system stability and compliance are maintained.

2. Scope

This Policy applies to all internally developed applications, APIs, microservices, and supporting systems (including third-party components and open-source dependencies). It encompasses both security patches and feature updates across all environments — development, staging, and production.

3. Objectives

  • Ensure timely application of patches and updates to maintain system integrity and security.
  • Reduce exposure to known vulnerabilities in software dependencies and environments.
  • Implement consistent and auditable processes for testing, approval, and deployment of patches.
  • Support the continuous improvement and reliability of software through structured version control and release practices.

4. Patch Identification and Classification

Patches and updates are identified through multiple sources and classified by priority and risk:

  • Security patches – Address vulnerabilities identified internally, through vendor advisories, or third-party reports.
  • Feature updates – Include new features, enhancements, or performance improvements requested by business stakeholders.
  • Bug fixes – Resolve functional or performance defects identified during development or in production.
  • Emergency patches – Critical fixes applied outside normal release cycles due to urgent security or operational needs.

5. Patch Evaluation and Testing

All patches must be evaluated for relevance, risk, and compatibility before deployment:

  • Development teams assess the potential impact and dependencies for each patch.
  • Patches undergo functional, regression, and security testing in isolated environments.
  • Feature updates are validated for performance, usability, and backward compatibility.
  • Automated testing and continuous integration pipelines are used to verify changes where applicable.

6. Approval and Change Management

All patches and updates must follow established change control procedures:

  • Each patch must be reviewed and approved by a designated team lead or release manager before deployment.
  • High-risk or emergency patches require additional sign-off from the Information Security Officer or Engineering Director.
  • Change requests must document patch details, risk level, testing outcomes, and rollback plans.
  • All approved patches are tracked through the company’s change management or ticketing system.

7. Deployment and Scheduling

Patches are deployed according to established schedules and business priorities, balancing timely application with operational stability:

  • Security patches must be deployed within 30 days of release, or sooner if actively exploited.
  • Feature updates and minor enhancements follow the standard release cadence (e.g., bi-weekly or monthly).
  • Emergency patches may be applied outside regular maintenance windows with expedited approval.
  • Deployment activities must include validation of post-deployment performance and user impact.

8. Dependency and Third-Party Component Management

All open-source libraries, frameworks, and third-party packages must be monitored and updated regularly to reduce vulnerability risk:

  • Automated tools (e.g., Dependabot, Snyk, or OWASP Dependency-Check) must be used to track outdated or vulnerable dependencies.
  • Version pinning and changelog reviews are required before updating critical dependencies.
  • Third-party updates must be tested in development environments before integration into production.

9. Rollback and Contingency Planning

If a patch causes unexpected behavior or system instability, rollback procedures must be initiated immediately to restore normal operations:

  • All deployments must include predefined rollback procedures and validated backups.
  • Rollback decisions are made collaboratively between the DevOps, QA, and Security teams.
  • Root cause analysis is performed for any failed or reverted patch to prevent recurrence.

10. Documentation and Audit

Comprehensive documentation must be maintained for all patching activities to ensure transparency and compliance:

  • Patch records must include version numbers, release dates, test results, and approval logs.
  • Audit logs must capture deployment timestamps, responsible personnel, and any exceptions or errors.
  • Periodic audits verify adherence to patch timelines and policy requirements.

11. Compliance and Reporting

Compliance with this Policy supports the Company’s broader information security and regulatory obligations. Reports on patch status, vulnerabilities, and exception handling must be reviewed by management on a quarterly basis.

12. Policy Review and Maintenance

This Policy will be reviewed annually or following major software platform or infrastructure changes. Updates must be approved by Executive Management and communicated to all relevant stakeholders.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Personnel Security and Termination Policy

Effective Date: October 30, 2025
Applies To: All employees, contractors, and third-party personnel engaged by Kingfield Software with access to company systems, facilities, or data.

1. Purpose

The purpose of this Personnel Security and Termination Policy is to ensure that all personnel employed, contracted, or otherwise engaged by Kingfield Software are properly screened, trained, and managed to protect the confidentiality, integrity, and availability of the Company’s information assets. This policy also establishes procedures for managing personnel transitions, including secure termination and access revocation.

2. Scope

This Policy applies to all full-time employees, part-time employees, contractors, consultants, interns, and third parties who have access to Company systems, data, or facilities. It governs the processes for onboarding, ongoing employment, and termination or contract completion.

3. Objectives

  • Reduce the risk of human-related security incidents through background screening and training.
  • Ensure personnel understand and uphold security responsibilities throughout their engagement.
  • Protect Company and customer data during onboarding, employment, and termination.
  • Ensure timely revocation of access rights upon employee departure or contract end.

4. Pre-Employment Screening

All personnel must undergo screening appropriate to the level of access and responsibility assigned. Screening may include:

  • Verification of identity, employment history, and professional references.
  • Criminal background checks where legally permitted and appropriate to the role.
  • Verification of education, certifications, or qualifications for sensitive technical or security roles.
  • Confirmation of right to work and compliance with applicable labor laws.

5. Employment Agreements

  • All personnel must sign confidentiality and acceptable use agreements before being granted access to Company resources.
  • Employment or contractor agreements must include clauses related to data protection, intellectual property, and compliance with Company policies.
  • Access to systems or sensitive data must not be provided until all required documentation is completed.

6. Roles and Responsibilities

  • Employees are responsible for safeguarding credentials, devices, and access to information systems.
  • Managers must ensure personnel receive appropriate security training and comply with policies.
  • The Information Security Officer oversees security awareness programs and access control procedures.
  • HR is responsible for ensuring onboarding and offboarding procedures are executed consistently.

7. Security Awareness and Training

  • All personnel must complete security awareness training upon hire and annually thereafter.
  • Training must include topics such as data protection, phishing prevention, and incident reporting procedures.
  • Completion of training must be documented and tracked by HR or the Information Security team.

8. Access Control and Privilege Management

  • Access to systems and data must be provisioned on the principle of least privilege.
  • Managers must request and approve access based on role and job function.
  • Periodic reviews of user access rights must be performed at least quarterly.
  • Temporary or contractor access must have defined expiration dates.

9. Disciplinary Action

Violations of security policies or misuse of Company systems may result in disciplinary actions up to and including termination, depending on the severity of the infraction and applicable employment laws.

10. Termination Procedures

  • HR and management must coordinate with IT to ensure timely revocation of access to all Company systems and data upon termination.
  • All Company property, including laptops, access cards, and mobile devices, must be returned prior to or on the last day of employment.
  • Departing personnel must acknowledge ongoing confidentiality obligations as outlined in their employment agreement.
  • Exit interviews should be conducted to reinforce data protection obligations and retrieve feedback on potential security issues.

11. Post-Termination Security Measures

  • Access credentials must be disabled immediately upon termination.
  • Email forwarding and data access must be reviewed and removed within 24 hours.
  • Former employees must not retain or access Company data, credentials, or systems after departure.
  • Audit logs should be reviewed to confirm all access has been terminated.

12. Third-Party and Contractor Termination

  • Contracts with third parties must include termination clauses addressing data handling and access revocation.
  • Contractor access must be disabled immediately upon project completion or contract termination.
  • All contractor-provided systems or credentials must be revoked, and any stored Company data must be securely deleted.

13. Compliance and Audit

Periodic audits must verify compliance with personnel security and termination procedures. Findings must be documented and remediation tracked to ensure continuous improvement.

14. Policy Review and Maintenance

This Policy will be reviewed annually or upon significant organizational or regulatory changes. Updates must be approved by Executive Management and communicated to all personnel.

15. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Physical Security Policy

Effective Date: October 30, 2025
Applies To: All facilities, data centers, and work environments utilized by Kingfield Software, including third-party hosting providers such as Amazon Web Services (AWS) and remote employee home offices.

1. Purpose

The purpose of this Physical Security Policy is to define the measures and responsibilities for protecting Kingfield Software information systems and assets from physical threats, unauthorized access, and environmental hazards. This policy covers both the physical security controls implemented by third-party hosting providers, such as AWS, and the requirements for secure remote work environments maintained by Company personnel.

2. Scope

This Policy applies to all physical and virtual environments supporting Kingfield Software applications, including AWS data centers, supporting infrastructure, and home offices of authorized personnel. It covers facility access, environmental protection, equipment handling, and physical data security.

3. Objectives

  • Ensure physical access to computing infrastructure is restricted to authorized personnel only.
  • Protect data center and endpoint equipment from theft, damage, and environmental risks.
  • Define physical security standards for remote employees handling company systems and data.
  • Ensure compliance with industry standards such as ISO 27001, SOC 2, and NIST SP 800-53.

4. Data Center and Hosting Provider Security

Kingfield Software leverages Amazon Web Services (AWS) and other third-party hosting providers for infrastructure operations. These providers maintain industry-leading physical security measures that comply with global standards, including ISO 27001, SOC 1, SOC 2, and PCI DSS.

  • Physical access to data centers is restricted to authorized personnel via multi-factor authentication, including biometric scanning and keycard access.
  • 24x7 on-site security staff, surveillance cameras, and intrusion detection systems monitor all access points.
  • Data centers are housed in unmarked facilities with redundant physical and environmental controls.
  • Environmental safeguards include fire suppression, climate control, and flood protection systems.
  • Access logs, video footage, and physical audit trails are maintained and reviewed regularly by AWS compliance teams.

5. Kingfield Software Responsibilities for Hosted Infrastructure

  • Ensure that all third-party providers, including AWS, maintain appropriate physical security certifications and audit reports.
  • Review SOC 2 Type II and ISO 27001 attestations annually to confirm compliance with required physical controls.
  • Restrict administrative access to production systems to authorized personnel only through secure VPN and multi-factor authentication.
  • Ensure data encryption is applied to protect information both in transit and at rest, reducing physical media exposure risks.
  • Conduct periodic reviews of vendor-provided physical security measures as part of vendor risk assessments.

6. Remote and Home Office Security

As Kingfield Software operates remotely, employees must maintain secure working environments that protect company systems and data from unauthorized access or disclosure.

  • Workstations and laptops must be physically secured when not in use (e.g., locked room or cable lock).
  • Company devices must never be left unattended in public or shared spaces.
  • Access to work devices must require strong authentication (e.g., passwords, biometrics, or MFA).
  • Home Wi-Fi networks must be password-protected and configured with WPA2 or higher encryption.
  • Family members, guests, or other non-employees must not use devices or systems containing Company data.
  • Sensitive conversations or video meetings should be conducted in private areas to prevent inadvertent disclosure.

7. Media and Asset Management

All physical media and computing devices that contain or process Company data must be controlled and protected from unauthorized removal or disposal.

  • Removable media (e.g., USB drives, external hard drives) must be encrypted and approved by IT before use.
  • Devices must be sanitized or securely destroyed before disposal or transfer.
  • AWS and other hosting providers are responsible for secure destruction of decommissioned storage devices per NIST 800-88 standards.
  • Asset inventories must track all Company-owned devices and their assigned personnel.

8. Environmental and Facility Safeguards

  • AWS data centers implement redundant power systems, fire detection, and suppression systems to ensure high availability.
  • All facility systems are monitored for temperature, humidity, and water intrusion.
  • Backup generators and uninterruptible power supplies (UPS) ensure continuity of operations during outages.
  • Kingfield Software relies on these safeguards as part of its shared responsibility model with AWS.

9. Incident Response and Physical Breaches

Any suspected or confirmed physical security incident involving Company systems, employee devices, or cloud infrastructure must be reported immediately to the Information Security Officer. AWS and other cloud providers notify customers of any confirmed physical incidents impacting customer systems or data per their contractual and compliance obligations.

  • Physical incidents include theft, break-ins, unauthorized access attempts, or environmental damage to hardware.
  • Kingfield Software will coordinate with AWS and relevant law enforcement or regulatory agencies if needed.
  • Incident reports and remediation actions must be documented according to the Company’s Incident Management Policy.

10. Policy Review and Maintenance

This Policy will be reviewed annually or following significant changes in hosting providers, operations, or regulatory requirements. Updates must be approved by Executive Management and communicated to all personnel.

11. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Privacy Policy

Effective Date: October 30, 2025
Applies To: All users of Kingfield Software’s websites, software applications, and related online services.

1. Purpose

The purpose of this Privacy Policy is to inform users of Kingfield Software’s practices regarding the collection, use, disclosure, and protection of personal information. This Policy is designed to ensure transparency, comply with applicable privacy laws such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA), and demonstrate the Company’s commitment to protecting user privacy.

2. Scope

This Policy applies to all personal information collected by Kingfield Software through its websites, software applications, and other digital services, including data submitted by users, customers, and visitors.

3. Information We Collect

Kingfield Software may collect the following categories of information from users and visitors:

  • Personal identifiers such as name, email address, phone number, and company name.
  • Account credentials such as usernames and passwords (encrypted and securely stored).
  • Technical data such as IP address, browser type, operating system, and device identifiers.
  • Usage information such as pages visited, actions taken in the application, and interaction timestamps.
  • Communication data provided when contacting customer support or filling out online forms.
  • Cookies and similar technologies to enhance website functionality and analytics (see Section 8).

4. How We Use Information

  • To provide, maintain, and improve our applications and services.
  • To communicate with users about updates, support, and service-related announcements.
  • To personalize user experiences and optimize site and application performance.
  • To detect, prevent, and respond to security incidents, fraud, or unauthorized access.
  • To comply with legal obligations and enforce terms of service.

5. Legal Basis for Processing (GDPR)

  • User consent for optional data collection, such as cookies or marketing communications.
  • Performance of a contract to provide requested services or fulfill user requests.
  • Legitimate business interests such as improving services and maintaining security.
  • Compliance with legal obligations applicable to the Company.

6. Information Sharing and Disclosure

Kingfield Software does not sell personal data. Information may be shared only as necessary to provide services or comply with law:

  • With service providers and partners (e.g., AWS, analytics providers) under contractual confidentiality and security obligations.
  • When required by law, subpoena, or regulatory request.
  • In connection with a business transfer, merger, or acquisition, provided appropriate safeguards are applied.
  • With the user’s consent, for any optional third-party integrations or data transfers.

7. Data Retention

Personal information will be retained only as long as necessary to fulfill the purposes outlined in this Policy or as required by law. When data is no longer needed, it will be securely deleted or anonymized in accordance with Kingfield Software’s Data Destruction and Retention Policy.

8. Cookies and Tracking Technologies

  • Kingfield Software uses cookies and similar technologies to enhance user experience, analyze usage, and improve service performance.
  • Users can manage cookie preferences through their browser settings or by adjusting consent banners on the website.
  • Essential cookies required for functionality cannot be disabled.

9. Data Security

Kingfield Software implements appropriate technical and organizational measures to safeguard personal information from unauthorized access, alteration, disclosure, or destruction.

  • Data is encrypted in transit and at rest using industry-standard protocols.
  • Access to systems and data is restricted through authentication and authorization controls.
  • Systems are hosted in secure AWS environments with physical and network protections.
  • Regular vulnerability assessments, patch management, and monitoring are conducted.

10. Data Subject Rights

  • Access – Users may request copies of their personal information.
  • Correction – Users may update or correct inaccurate or incomplete data.
  • Deletion – Users may request deletion of their personal information, subject to legal or contractual obligations.
  • Restriction and Objection – Users may limit processing or object to specific data uses.
  • Portability – Users may request their information in a machine-readable format.

Requests to exercise these rights may be submitted to the contact information provided in Section 14. Kingfield Software will respond to all legitimate requests in accordance with applicable laws.

11. International Data Transfers

Personal data may be processed or stored in countries outside of the user’s home jurisdiction. Where data transfers occur, Kingfield Software ensures appropriate safeguards are in place, such as Standard Contractual Clauses (SCCs) or equivalent legal mechanisms.

12. Children’s Privacy

Kingfield Software’s services are not directed to children under 13 years of age (or 16, where applicable). We do not knowingly collect personal information from minors. If we become aware of such collection, the data will be deleted promptly.

13. Updates to This Policy

This Privacy Policy may be updated periodically to reflect changes in law, technology, or business operations. Updated versions will be posted with revised effective dates.

14. Contact Information

For any privacy-related inquiries, requests, or complaints, please contact: Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Server Security Policy

Effective Date: October 30, 2025
Applies To: All Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances deployed by Kingfield Software for development, staging, and production environments.

1. Purpose

The purpose of this Server Security Policy is to define security requirements and operational standards for all Amazon EC2 instances used by Kingfield Software. This Policy ensures that all servers are configured, maintained, and monitored in accordance with industry best practices and applicable compliance frameworks such as ISO 27001, SOC 2, and NIST SP 800-53.

2. Scope

This Policy applies to all EC2 instances provisioned and managed by Kingfield Software within AWS accounts owned or operated by the Company. It covers configuration, patching, access control, monitoring, and data protection measures applied to all EC2 systems.

3. Objectives

  • Ensure consistent and secure configuration of all EC2 instances.
  • Restrict and monitor access to server resources.
  • Protect data stored or processed on EC2 instances from unauthorized access or modification.
  • Ensure compliance with applicable legal, regulatory, and contractual security requirements.

4. EC2 Instance Provisioning

  • All EC2 instances must be launched using approved Amazon Machine Images (AMIs) that are hardened and maintained by the DevOps or Security team.
  • Default AWS Security Groups must be reviewed and modified to follow least-privilege principles.
  • Unnecessary ports and services must be disabled prior to deployment.
  • Instances must be deployed within Virtual Private Clouds (VPCs) with properly configured subnets and routing tables.
  • Elastic IP addresses must only be used for instances requiring direct internet access and must be protected by appropriate firewall rules.

5. Access Control

  • Access to EC2 instances must be managed through AWS Identity and Access Management (IAM) roles, not permanent credentials.
  • All SSH access must use key-based authentication with unique SSH key pairs per user or system.
  • Root account access must be disabled or tightly restricted; all administrative tasks should be performed using IAM roles with MFA.
  • Access logs and CloudTrail records must be reviewed regularly to detect unauthorized login attempts.
  • Temporary access credentials (e.g., session tokens) must expire automatically within a reasonable period (e.g., 12 hours).

6. Server Hardening

  • Remove or disable all unused system accounts and default credentials.
  • Ensure that only required packages and services are installed on each EC2 instance.
  • Implement file integrity monitoring tools to detect unauthorized changes.
  • Configure system firewalls (iptables, AWS Security Groups) to restrict inbound and outbound network traffic.
  • Install intrusion detection agents (e.g., AWS Inspector, GuardDuty, or equivalent) on all production servers.

7. Patch Management

  • Operating system and application patches must be applied within 30 days of release or sooner if they address critical vulnerabilities.
  • Automated patching solutions (e.g., AWS Systems Manager Patch Manager) should be used where feasible.
  • Security updates must be tested in staging environments before production rollout.
  • Servers must be rebooted or refreshed as necessary to ensure patches take effect.

8. Monitoring and Logging

  • Enable AWS CloudTrail, CloudWatch, and VPC Flow Logs to record all relevant system and network activity.
  • Logs must be stored in centralized, access-controlled AWS S3 buckets or logging services with retention periods of at least 12 months.
  • Automated alerts must be configured for unauthorized access attempts, resource misconfigurations, and policy violations.
  • Audit logs must be reviewed monthly by the Security or DevOps team.

9. Backup and Recovery

  • Regular backups of EC2 instances must be performed using AWS Backup or equivalent services.
  • Backup data must be encrypted at rest and in transit using AWS Key Management Service (KMS).
  • Backups must be stored in separate AWS regions or accounts to ensure disaster recovery resilience.
  • Periodic restoration tests must be conducted to validate backup integrity and recovery procedures.

10. Decommissioning

Before terminating any EC2 instance, all data must be securely deleted or transferred in accordance with the Company’s Data Destruction and Retention Policy. Termination procedures must ensure that storage volumes (EBS) are wiped using AWS secure deletion processes.

11. Compliance and Review

This Policy will be reviewed annually or following major infrastructure or security control changes. Compliance will be validated through periodic internal audits and vulnerability assessments.

12. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Scanning and Security Policy

Effective Date: October 30, 2025
Applies To: All applications, EC2 instances, and cloud infrastructure assets managed by Kingfield Software within Amazon Web Services (AWS) environments.

1. Purpose

The purpose of this Scanning and Security Policy is to establish a framework for identifying, assessing, and remediating security vulnerabilities across Kingfield Software’s AWS-hosted infrastructure and applications. This Policy ensures continuous visibility into potential risks and compliance with industry security standards such as ISO 27001, SOC 2, and NIST SP 800-53.

2. Scope

This Policy applies to all systems and services operated by Kingfield Software within AWS, including EC2 instances, application code, APIs, databases, and software dependencies. It encompasses vulnerability scanning, code analysis, and configuration assessments across development, staging, and production environments.

3. Objectives

  • Identify and remediate vulnerabilities that could expose applications or infrastructure to compromise.
  • Ensure consistent use of automated and manual security scanning processes.
  • Integrate scanning results into patch management and incident response workflows.
  • Support compliance with security and data protection frameworks through documented vulnerability management processes.

4. Roles and Responsibilities

  • The Security Team oversees vulnerability management processes and ensures compliance with this Policy.
  • The DevOps Team manages scanning tools, schedules scans, and validates remediation of vulnerabilities.
  • The Development Team addresses vulnerabilities in application code, libraries, and dependencies.
  • Management ensures adequate resources and prioritization for security remediation activities.

5. Vulnerability Scanning Standards

  • Automated vulnerability scans must be performed on all EC2 instances at least monthly using AWS Inspector or equivalent tools.
  • Container images and application builds must be scanned prior to deployment using static and dynamic analysis tools.
  • Dependency and package vulnerability scans must be run on all code repositories at least weekly using tools such as Snyk or Dependabot.
  • All externally exposed assets must be scanned for open ports, misconfigurations, and outdated software components.
  • Cloud infrastructure configuration assessments must be conducted using AWS Config, Security Hub, or equivalent.

6. Vulnerability Classification

Vulnerabilities must be classified based on severity using the Common Vulnerability Scoring System (CVSS) or equivalent risk model:

  • Critical – CVSS score 9.0–10.0: Immediate remediation required (within 24–48 hours).
  • High – CVSS score 7.0–8.9: Must be remediated within 7 days.
  • Medium – CVSS score 4.0–6.9: Must be remediated within 30 days.
  • Low – CVSS score 0.1–3.9: Remediate during the next scheduled maintenance cycle.

7. Remediation and Verification

  • Identified vulnerabilities must be logged in the Company’s tracking system and assigned to responsible teams for remediation.
  • All critical and high vulnerabilities must be validated after patching to confirm successful mitigation.
  • Remediation activities must follow the Company’s Patch Management and Change Management Policies.
  • Vulnerability exceptions or deferred fixes must be approved by the Security Officer and documented with justification.

8. Continuous Monitoring

  • AWS GuardDuty and CloudWatch must be enabled to monitor for anomalous activity and potential intrusions.
  • Automated alerts must notify the Security Team of critical vulnerabilities or misconfigurations in real-time.
  • All security findings must be correlated with system and network logs to detect possible exploitation attempts.
  • Metrics related to vulnerability counts, remediation rates, and scanning coverage must be reviewed quarterly.

9. Reporting and Metrics

  • Monthly vulnerability reports must be generated summarizing scan results, remediation timelines, and compliance status.
  • Critical findings must be reported immediately to management with proposed mitigation plans.
  • Trend analysis must be conducted to identify recurring issues and improve preventive measures.

10. Integration with Incident Response

If a vulnerability is determined to have been exploited, it must be treated as a security incident and escalated according to the Company’s Incident Management Policy.

  • The Security Team must perform root cause analysis and document lessons learned.
  • Post-incident remediation and patch verification must be completed before systems are returned to service.
  • Updated controls must be implemented to prevent similar vulnerabilities from recurring.

11. Compliance and Audit

This Policy supports compliance with applicable information security standards and customer requirements. Periodic audits will verify adherence to scanning frequency, remediation timelines, and documentation practices.

12. Policy Review and Maintenance

This Policy will be reviewed annually or following significant infrastructure, tooling, or regulatory changes. Updates must be approved by Executive Management and communicated to all relevant teams.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Server Audit Policy

Effective Date: October 30, 2025
Applies To: All Amazon Web Services (AWS) EC2 instances and supporting infrastructure managed by Kingfield Software.

1. Purpose

The purpose of this Server Audit Policy is to establish a consistent and structured approach for auditing Kingfield Software’s server environments hosted in AWS. This policy ensures that all EC2 instances and related systems are periodically reviewed to verify compliance with configuration, access, and security requirements.

2. Scope

This policy applies to all AWS EC2 instances and associated systems operated by Kingfield Software in development, staging, and production environments. It covers access control reviews, configuration audits, security verification, and log review procedures.

3. Objectives

  • Ensure all EC2 instances comply with Kingfield Software’s security and configuration standards.
  • Identify deviations, misconfigurations, and unauthorized changes.
  • Provide evidence of compliance for internal and external audits.
  • Support continuous improvement of security posture and operational controls.

4. Audit Frequency

Server audits must be conducted at least quarterly, or more frequently when significant infrastructure or configuration changes occur. Additional audits may be performed following security incidents, compliance assessments, or requests from management.

5. Roles and Responsibilities

  • The Security Team is responsible for defining audit procedures, reviewing results, and maintaining audit records.
  • The DevOps Team supports the audit process by providing system data, configuration details, and evidence of control implementation.
  • Management ensures that corrective actions identified during audits are prioritized and completed within required timelines.

6. Audit Process

  • Review system configurations to verify compliance with baseline security and operating standards.
  • Evaluate IAM roles, groups, and policies to ensure proper segregation of duties and least-privilege access.
  • Examine network configurations, including Security Groups, firewalls, and routing tables, for alignment with approved architecture.
  • Confirm logging and monitoring controls are enabled and functioning properly across EC2 instances.
  • Verify that operating systems and applications are updated with the latest security patches.
  • Check backup schedules and restoration procedures for consistency with the Company’s Backup Policy.

7. Evidence Collection

Auditors must document evidence collected during each review, including screenshots, configuration exports, and access logs. All evidence must be securely stored in the Company’s designated audit repository within AWS or another approved platform.

8. Reporting and Findings

  • Audit results must be documented in a formal report, including identified issues, risk ratings, and recommended remediation actions.
  • Critical findings must be communicated to management within 24 hours of discovery.
  • All reports must be retained for a minimum of three years for compliance and review purposes.

9. Corrective Actions

Findings from audits must be tracked to resolution. Remediation plans should include the assigned responsible party, completion date, and validation evidence.

  • High-risk findings must be remediated within 30 days of discovery.
  • Medium-risk findings must be remediated within 60 days.
  • Low-risk findings should be addressed during routine maintenance or next scheduled update.

10. Compliance Verification

Audit findings and remediation status must be reviewed by management and verified through follow-up audits. Non-compliance may result in corrective measures or escalation as required by the Company’s governance framework.

11. Record Retention

All audit records, including reports, evidence, and remediation documentation, must be retained for a minimum of three years. Records must be stored securely with access restricted to authorized personnel only.

12. Policy Review

This Policy will be reviewed annually or following significant changes in infrastructure, regulations, or business operations. Revisions will be approved by Executive Management and communicated to all relevant personnel.

13. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Third-Party Access Policy

Effective Date: October 30, 2025
Applies To: All third-party individuals and organizations that access Kingfield Software systems, applications, or data.

1. Purpose

The purpose of this Third-Party Access Policy is to define the requirements and procedures governing third-party access to Kingfield Software systems, networks, and data. This Policy ensures that any external access to Company resources is appropriately authorized, controlled, monitored, and terminated to protect information assets and maintain compliance with security standards.

2. Scope

This Policy applies to all third parties—including vendors, contractors, service providers, consultants, auditors, and partners—who are granted access to Kingfield Software’s systems, applications, or data. It covers all environments, including development, staging, and production, as well as any remote connections or API integrations.

3. Objectives

  • Ensure all third-party access is based on a valid business need and is properly authorized.
  • Minimize security risks associated with third-party connections and integrations.
  • Define clear roles, responsibilities, and approval processes for managing third-party access.
  • Ensure third-party compliance with applicable security and confidentiality requirements.

4. Access Authorization

  • All third-party access must be requested and approved in writing by an authorized manager or system owner.
  • Each access request must specify the scope, duration, and purpose of access.
  • Third parties must sign a Non-Disclosure Agreement (NDA) before being granted access to systems or data.
  • Access credentials must be assigned to individuals, not shared among organizations or teams.
  • All access must be temporary and reviewed for renewal upon expiration.

5. Access Control and Authentication

  • Third-party users must be provided only the minimum level of access required to perform their tasks (principle of least privilege).
  • All access must be authenticated using multi-factor authentication (MFA) where supported.
  • AWS IAM roles or temporary access credentials should be used for vendor integrations.
  • Remote administrative access must occur over secure channels (e.g., SSH or VPN).
  • Default or generic accounts are prohibited for third-party use.

6. Security Requirements for Third Parties

  • Third parties must adhere to Kingfield Software’s Information Security, Data Protection, and Privacy Policies.
  • Vendors must implement appropriate physical, administrative, and technical safeguards to protect Company data.
  • Third parties must notify Kingfield Software immediately of any suspected or confirmed security incident involving Company information.
  • Access credentials and data must not be stored, shared, or transmitted in insecure ways (e.g., email, plaintext).
  • Subcontracting of services involving access to Company systems is prohibited without prior written approval.

7. Monitoring and Logging

  • All third-party access must be logged and monitored to detect unauthorized activity.
  • Access logs must include timestamps, user identification, systems accessed, and actions performed.
  • Logs must be reviewed regularly by the Security Team for anomalies or policy violations.
  • Suspicious or unauthorized activity must be investigated and reported in accordance with the Incident Management Policy.

8. Review and Renewal of Access

  • Third-party access must be reviewed quarterly to ensure ongoing business justification.
  • Expired or inactive accounts must be deactivated immediately.
  • Renewal of access requires reauthorization and review of security controls.
  • Audit results must be documented and retained for at least one year.

9. Termination of Access

  • Access must be revoked immediately upon completion of work, contract termination, or detection of misuse.
  • The Security Team must verify that all accounts, keys, and credentials associated with the third party are disabled.
  • All Company data, media, or equipment in possession of the third party must be returned or securely destroyed.
  • The termination process must be documented, including date, responsible personnel, and confirmation of completed actions.

10. Compliance and Enforcement

Failure to comply with this Policy may result in termination of access, contract cancellation, or legal action as appropriate. Kingfield Software reserves the right to audit any third-party’s compliance with security requirements at any time.

11. Policy Review and Maintenance

This Policy will be reviewed annually or when significant changes occur to third-party relationships, systems, or regulatory requirements. Revisions must be approved by Executive Management and communicated to all relevant parties.

12. Contact

Charles Weed Email: info@kingfieldsoftware.com Phone: (651) 398-7580

Documents for Download

Access Control Policy

Business Continuity Policy

Data Destruction and Retention Policy

Data Security Policy

Disaster Recovery Policy

Email Use Policy

Encryption Policy

Exception Request Policy

Incident Management Policy

Internet Security Policy

Mobile Device Policy

Network Security Policy

Acceptable Use Policy

Password Policy

Patch Management Policy

Personnel Security and Termination Policy

Physical Security Policy

Privacy Policy

Server Security Policy

Scanning and Security Policy

Server Audit Policy

Third Party Access Policy

Contact Us: info@kingfieldsoftware.com