Organization Units

Regulation on the Structure and Work Processes of the Technology Unit of the Generation Z Organization

Chapter One: General

Article 1: Purpose

This regulation has been developed with the aim of determining the position, mission, structure, limits of authority, responsibilities and work processes of the Technology Unit of the Generation Z Organization.

The Technology Unit is responsible for designing, developing, maintaining, supporting and improving the infrastructure, systems, websites, digital tools and technological solutions required by the organization.

Article 2: Scope of Implementation

The provisions of this regulation are applicable to the manager, members, specialists, project colleagues, contractors and all persons who work in any way in the projects or infrastructures of the Technology Unit.

Other units of the organization are also obliged to comply with the processes related to registration of requests, access, information security and project delivery in cases where they use the services, systems or infrastructures of the Technology Unit.

Article 3: Definitions

In this regulation, the following terms are used in the meanings specified:

1. **Organization:** Generation Z organization.
2. **Unit:** Generation Z organization’s technology unit.
3. **Unit Manager:** Person appointed to manage the technology unit.
4. **Project:** A set of scheduled activities to create, develop or improve a product, service or technological infrastructure.
5. **Support Request:** Any report of a malfunction, need for access, technical change, training or operational assistance.
6. **Digital Asset:** Includes domain, host, server, code repository, user account, database, file, design, access key, security certificate, software and other technological resources belonging to the organization.
7. **Security Incident:** Any unauthorized access, information disclosure, cyber attack, data loss, account abuse or suspected disruption in systems.
8. **Operational Environment:** A system or infrastructure that is officially available to the organization's users or audiences.

---

Chapter Two: Mission and Duties of the Unit

Article 4: Mission of the Unit

The mission of the Technology Unit is to provide and develop the organization's technological capacity in order to increase the effectiveness, security, sustainability, speed and quality of the organization's activities.

In addition to responding to current needs, the Technology Unit must also plan for the development of future infrastructure and reduce the organization's dependence on external tools and individuals.

Article 5: Areas of Responsibility

The main duties of the Technology Unit are:

1. Design, develop and maintain the organization's websites and systems.

2. Manage technical infrastructure, servers, hosts, domains and databases.
3. Provide technical support to authorized units and users of the organization.
4. Design or deploy automation tools, information management and digital communications.
5. Evaluate and select software, services, and tools required by the organization.
6. Manage cybersecurity, access levels, and protect digital assets.
7. Prepare backups and plan for data recovery.
8. Document systems, access, technical decisions, and implementation processes.
9. Provide technical advice to management and other organizational units.
10. Define and implement development projects within the framework of the organization's goals.
11. Monitor contractors and technical service providers.
12. Train users on the correct and secure use of systems.
13. Identify new technologies and propose appropriate solutions to improve the organization's performance.
14. Manage the life cycle of the organization's digital products and services.
15. Prevent the creation of scattered systems, accounts, or infrastructure outside the organization's control.

---

Chapter Three: Unit Structure

Article 6: Basic Structure

The structure of the technology unit, in accordance with the needs and capacity of the organization, can include the following sections:

1. Technology Unit Management

2. Software and Web Development

3. Infrastructure and Technical Operations

4. Technical Support

5. Information Security

6. Data, Automation and Artificial Intelligence

7. Experience and User Interface Design

8. Quality Control and Testing

9. Documentation and Knowledge Management

Creation, merger, separation or elimination of any of the internal departments of the unit, within the limits of the organization's approved organization, is possible by decision of the unit manager.

Article 7: Executive Roles

Unit members may work in one or more of the following roles as needed:

* Project Manager
* Software Developer
* Infrastructure Manager or Expert
* Support Expert
* Security Expert
* Interface and User Experience Designer
* System or Data Analyst
* Automation and Artificial Intelligence Expert
* Tester or Quality Control Officer
* Documentation Officer
* Technical Specialist or Consultant
* Project Associate or Specialized Volunteer

The job description of each person must be in writing or recorded in the work management system.

Article 8: Experts and Consultants

Experts and consultants may cooperate with the organization to provide expert opinions, project evaluation, training, transfer experience, or increase the scientific and technical capacity of the unit.

Experts and consultants, unless issued a notification or official assignment of responsibility, do not have executive, managerial authority, or issue orders to unit members.

Their advisory opinions are not binding on the unit manager, unless otherwise specified in an official resolution.

---

Chapter Four: Management and Authority

Article 9: Position of the Unit Manager

The Technology Unit Manager is responsible for managing, coordinating, and supervising all technical and technological activities of the organization and has independent decision-making authority within the executive area of ​​the unit.

The Unit Manager is accountable to the superior authority designated in the organization's structure.

Article 10: Limits of the Unit Manager's Independence

The Unit Manager has independent decision-making authority in the following cases:

1. Determining technical methods and system architecture.

2. Selecting technology, programming language, framework, tools, and technical services.
3. Prioritizing requests and projects of the unit.
4. Dividing tasks among members.
5. Designating a person responsible for each project or system.
6. Approving or rejecting technical changes.
7. Temporarily stopping a system or access in the event of a security risk.
8. Determining Development, security, documentation, and quality control standards.
9. Selecting the project implementation method, including in-house implementation, outsourcing, or a hybrid model.
10. Approving the release of new versions of systems.
11. Creating, suspending, or revoking technical access.
12. Organizing project teams and groups within the unit.
13. Determining project management tools, communications, and document recording.
14. Rejecting requests that are not feasible from a technical, security, time, or resource perspective.
15. Proposing the recruitment, transfer, evaluation, or termination of technical members.

Article 11: Limitations on Independent Authority

The following decisions require the approval of the organization's competent authority:

1. Making a financial commitment outside the approved budget.
2. Entering into a formal contract with external individuals or companies.
3. Major hardware or software purchases.
4. Transferring ownership of the organization's digital assets.
5. Disseminating or transferring confidential data outside the organization.
6. Making a fundamental change in the organization’s public policies or official identity.
7. Decisions that have significant legal, financial, or political implications.
8. Permanently stopping the organization’s strategic systems.
9. Completely transferring the management of a sensitive infrastructure to an external person or entity.

In emergency situations, the unit manager can take immediate and temporary measures to prevent damage and is required to report it as soon as possible.

Article 12: Responsibilities of the Unit Manager

The unit manager is required to:

1. Prepare and update the unit’s executive plan.
2. Prioritize the unit’s projects and requests.
3. Monitor the quality, security, and sustainability of outputs.
4. Distribute responsibilities transparently among members.
5. Prevent the concentration of knowledge and access in the hands of one person.
6. Report the status of major projects to the higher authority.
7. Protect the organization's digital assets and information.
8. Mandate technical and management documentation.
9. Take charge of decision-making and crisis management in major technical or security incidents.
10. Identify and communicate the unit's human resources, budget, and infrastructure needs.

---

Chapter Five: Planning and Prioritization

Article 13: Work Plan

The unit's activities are planned in the following areas:

1. Strategic projects

2. Development projects

3. Maintenance and improvement of existing systems

4. Support requests

5. Security measures

6. Emergency activities

7. Research and technology evaluation

8. Documentation and training

Article 14: Prioritization criteria

The unit manager prioritizes requests and projects based on the following criteria:

1. Strategic importance to the organization

2. Urgency

3. Security or operational risk

4. Number of users or units affected

5. Impact on the organization's core activities

6. Human and technical resources required

7. Implementation time

8. Dependence on other projects

9. Implementation and maintenance costs

10. Technical feasibility

11. Legal, media or credit risk

12. Sustainability and future development potential

Consumption A request from an authority or unit alone does not constitute an urgent priority, unless the request has been notified by the competent authority as an urgent mission of the organization.

Article 15: Stopping or suspending a project

The unit manager may stop or suspend a project in the following cases:

* Lack of information or clear requirements

* Lack of sufficient human resources or resources

* Change in organizational priorities

* Existence of a security risk

* Dependence on the decision or action of another unit

* Lack of cooperation from the applicant

* Unreasonable increase in the scope of the project
* Continuation of the project becomes futile or uneconomical
* Contradiction with organizational policies

The reasons for stopping or suspending must be recorded and communicated to the relevant stakeholders.

---

Chapter Six: Process for registering and handling requests

Article 16: Registration of a request

All technical requests must be registered through the official channel designated by the technology unit.

A verbal request, personal message, or order scattered on social media does not create an executive obligation for the unit unless it is registered in an official channel.

The request should include the following as much as possible:

1. Description of the need or problem

2. Expected goal

3. Requesting unit or person

4. Level of urgency

5. Expected time

6. Affected users or audiences

7. Sample, file, or related information

8. Responsible person for the response from the requesting unit

Article 17: Initial review

After receiving the request, the technology unit reviews it in terms of technical, security, time, and resources.

The result of the review can be one of the following:

* Acceptance

* Conditional acceptance

Request for additional information

* Placement in the execution queue

* Referral to another unit

* Suspension

Rejection of the request

Rejection or suspension of the request must be accompanied by a reason.

Article 18: Emergency Requests

An emergency request includes cases that have caused one of the following conditions:

* Stoppage of the organization's main activity

* Loss of access to a critical system

* Possibility of information disclosure

* Unauthorized access

* Destruction or deletion of data

* Widespread disruption to users

* Direct threat to the organization's digital security

The final determination of whether a request is urgent rests with the unit manager or his/her designated official.

---

Chapter Seven: Project Development Process

Article 19: Project Implementation Stages

Development projects, depending on their size and importance, must go through the following stages:

1. Registration of a request or proposal
2. Definition of the problem and goal
3. Determination of the project scope
4. Analysis of requirements
5. Technical and security assessment
6. Determination of the project manager
7. Planning and division of tasks
8. Technical design and user interface
9. Development
10. Testing and quality control
11. Technical approval
12. Deployment
13. Delivery and training
14. Documentation
15. Post-implementation support and evaluation

The unit manager may combine some stages for small or urgent projects; provided that the security, quality, and traceability of the project are not compromised.

Article 20: Definition of the project scope

Before starting development, at least the following The following should be specified:

* Project Objective
* Expected Output
* Key Users
* Essential Features
* Out-of-scope Features
* Project Owner
* Dependencies
* Technical Constraints
* Acceptance Criteria
* Approximate Timeline

Any new request that falls outside the agreed scope should be reviewed and prioritized as a scope change.

Article 21: Ownership of Code and Outputs

All code, designs, documentation, databases, settings, files, and outputs produced within the scope of the unit's activities or with the organization's resources belong to the organization; unless otherwise specified in a written contract.

Members and contractors are required to store outputs in the organization's official repositories and spaces.

It is prohibited to store a single copy of a project in a personal account, personal computer, or space outside the organization's control.

Article 22: Code Repository and Version Control

All software projects must be stored in an official repository under the organization's control.

Major changes must have a trackable history and include a proper explanation of the purpose and nature of the change.

Deleting project history, unauthorized transfer of the repository, or storing source code outside of the official repository is prohibited.

Article 23: Quality Control

No major change shall be released to the operational environment without review commensurate with the level of risk.

Quality control may include the following:

* Code review
* Performance testing
* Security testing
* User interface testing
* Compatibility review
* Recovery testing
* Project manager approval
* Unit manager approval

---

Chapter 8: Deployment and Change Management

Article 24: Technical Environments

In major projects, development, test, and operational environments should be separated as much as possible.

Direct use of the operational environment to test high-risk changes is prohibited, except in emergency situations and with the approval of the unit manager.

Article 25: Release of Changes

Each major release must include at least the following:

1. Description of the change
2. Responsible for implementation
3. Implementation time
4. Backup or rollback method
5. Test result
6. Potential risks
7. Final deployment result

Article 26: Emergency change

In the event of a critical event, the unit manager or authorized person may implement an emergency change without going through all normal procedures.

The emergency change must be reviewed and, if necessary, modified after the documented crisis has been resolved.

---

Chapter Nine: Support and Maintenance

Article 27: Support Services

The unit's support services include the following:

* Troubleshooting systems
* Account and access management
* User guidance
* Error checking
* Infrastructure maintenance
* Software updates
* Security problem checking
* Data recovery within available capabilities
* Coordination with external service providers

Article 28: Handling level

Support requests are divided into the following levels based on the severity of the impact:

1. Critical: Main system outage, security incident, or widespread disruption.

2. High: Serious disruption without complete shutdown of activity.

3. Normal: Limited problem or routine operational request.

4. Low priority: Improvement, suggestion, or non-urgent request.

The handling time is determined based on the level of the request, team capacity, and technical conditions, and registering a request does not mean guaranteeing the requested time.

Article 29: User Responsibilities

Users are required to:

1. Provide the information necessary to investigate the problem.

2. Do not share their password with others.

3. Avoid installing or using unauthorized tools.

4. Report suspicious events immediately.

5. Avoid creating an organizational account or service without coordination.

6. Follow the unit's security and technical instructions.

7. Avoid sending confidential information on insecure channels.

---

Chapter Ten: Information Security and Access

Article 30: Principle of Least Access

Each person's access should be granted only to the extent necessary to perform their duties.

Organizational position alone does not provide full access to systems, data, or technical infrastructure.

Article 31: Creation and Revoking Access

Creation, modification, or revoking of technical access should be done with the approval of the unit manager or an authorized person.

At the end of the collaboration, change of responsibility or the emergence of a security risk, the person’s access should be revoked or restricted as soon as possible.

Article 32: Organizational Accounts

Accounts related to the domain, server, social network, cloud service, code repository and other organizational assets should be created with email and information under the control of the organization as much as possible.

The use of a personal phone number, email or account for strategic assets is not permitted, except in temporary circumstances and with official registration.

Article 33: Authentication and Passwords

Strong passwords and multi-factor authentication should be used for sensitive systems.

Passwords, access keys and sensitive information should not be recorded in public messages, insecure files or source code.

Article 34: Security Incident

Any member or user is required to immediately notify the unit administrator or security officer if they observe a security incident.

The unit administrator has the authority to:

* Suspend access.

* Temporarily remove access to the system.

* Change passwords and keys.
* Disconnect a service.
* Restore a suspicious copy or change.
* Initiate a technical review and record evidence.

Public notification of a security incident shall only be made in coordination with the responsible authority in the organization.

---

Chapter Eleven: Data and Backup

Article 35: Data Management

Organizational data shall be managed based on the level of sensitivity, use, and risk of disclosure.

Access, transfer, deletion, extraction, or dissemination of sensitive data without authorization shall be prohibited.

Article 36: Backup

A backup schedule shall be determined for critical systems commensurate with their importance.

Backups shall, to the extent possible:

* Be prepared regularly.

* Be separate from the main system.

* Be protected against unauthorized access.

* Be periodically tested and restored.
* Have a specific retention period.

The existence of a backup copy without a recovery test does not guarantee the ability to recover information.

Article 37: Deletion of information

Permanent deletion of data, projects, repositories or master accounts must be carried out with the approval of the unit manager and after reviewing the consequences.

In cases with legal, security or organizational implications, obtaining approval from the competent authority is also required.

---

Chapter 12: Documentation and Knowledge Management

Article 38: Documentation Requirement

All important projects and infrastructure must have adequate documentation.

The documentation includes the following as appropriate:

* System architecture
* Installation and deployment method
* Dependency information
* Database structure
* Backup and recovery method
* Service list
* User guide
* Technical decision records
* Authorities and access levels
* Error and crisis management method

Article 39: Preventing individual dependency

No critical system should be managed in such a way that only one person can maintain, access or recover it.

The unit manager is required to provide at least one alternative path for access, documentation and knowledge transfer for critical infrastructure.

Article 40: Handover

In the event of a member's change or termination of cooperation, he is required to:

1. Hand over all files and codes.

2. Announce the status of open tasks.

3. Introduce related accesses and accounts.
4. Complete the necessary documentation.
5. Transfer the necessary knowledge to the replacement person.
6. Remove the organization's information from personal spaces, except in cases where its retention is authorized by written permission.

---

Chapter Thirteen: Cooperation with Other Units

Article 41: Requester's Representative

For each important project, the requesting unit must introduce a specific representative.

The requesting representative is responsible for presenting the requirements, answering questions, reviewing the output, and making the final decision.

Delays by the representative in presenting information or approving the output can cause changes to the project schedule.

Article 42: Separation of Responsibilities

The technology unit is responsible for selecting and implementing the technical solution.

The requesting unit is responsible for defining the need, content, technical rules, accuracy of the information, and validating the output.

The technology unit is not responsible for the political, legal, media, or content accuracy of information provided by other units, unless this responsibility has been explicitly assigned to the unit.

Article 43: Direct Requests from Members

Other managers and members of the organization should not assign a task directly to members of the Technology Unit without coordinating with the Unit Manager.

Requests must be registered and prioritized through the official Unit channel.

Unit members are required to refer requests outside of this process to the Unit Manager or Project Manager.

---

Chapter Fourteen: Contractors and External Services

Article 44: Contractor Selection

The Technology Unit is responsible for the technical evaluation of the contractor, software, or external service.

In cases involving financial or legal obligations, the final selection is made in accordance with the regulations and authorities of the Organization.

Article 45: External Collaboration Requirements

External contractors and collaborators must commit to the following, as applicable:

* Confidentiality

* Organization ownership of outputs

* Delivery of code and documentation

* Compliance with security requirements

* Restriction of data use

* Removal of access after the end of the collaboration

* Declaration of use of third-party tools or services

* Complete delivery of created accounts and assets

Article 46: Contractor Access

Contractor access must be limited, temporary, and revocable.

Granting full or permanent access to the organization’s infrastructure without technical necessity and approval from the unit manager is prohibited.

---

Chapter Fifteen: Reporting and Evaluation

Article 47: Performance Report

The unit manager must submit a report on the status of the unit at appropriate intervals.

The report may include the following:

* Active and completed projects
* Major support requests
* Infrastructure status
* Security incidents
* Risks and obstacles
* Human and financial resource needs
* Next period plan
* Sustainability and performance indicators

Article 48: Evaluation indicators

The performance of the unit may be evaluated based on the following indicators:

1. Project implementation rate
2. Quality and stability of systems
3. Speed ​​of handling major disruptions
4. Number and severity of security incidents
5. Quality of documentation
6. Internal user satisfaction
7. Reduction in manual work
8. Level of dependence on external individuals or services
9. Compliance with security and quality control standards
10. Cost-effectiveness of results

The evaluation of the unit should not be based solely on the number of requests closed or apparent speed; quality, security and sustainability should also be considered.

---

Chapter 16: Confidentiality and Professional Conduct

Article 49: Confidentiality

Members of the Unit are required to keep the technical information, codes, data, system structure, vulnerabilities and internal information of the organization confidential.

This obligation continues after the end of the cooperation.

Article 50: Conflict of Interest

Members of the Unit must declare any personal, financial or professional interest related to the selection of the contractor, software or service.

Personal or commercial use of the data, infrastructure or codes of the organization without permission is prohibited.

Article 51: Professional Conduct

Members of the Unit are required to:

* Follow up on accepted responsibilities.

* Do not hide problems and delays.

* Do not provide incorrect information about the status of the project.

* Do not make risky changes without coordination.

* Maintain documentation and work records.
* Behave professionally in relation to users and other units.
* Avoid creating knowledge monopoly or personal access.

---

Chapter Seventeen: Violations

Article 52: Examples of Violations

The following are considered violations of this regulation:

1. Disclosure of passwords or confidential information.

2. Unauthorized access to data or systems.

3. Deliberate deletion of code, data or documentation.
4. Creating an organizational account or infrastructure outside the organization’s control.
5. Transferring digital assets to a personal account without authorization.
6. Uncoordinated release of risky changes.
7. Refusing to hand over code, information, or access.
8. Personal or commercial use of organization resources.
9. Installing or using unsafe or unauthorized tools.
10. Concealing a security incident or critical error.
11. Bypassing the official process of projects and requests.
12. Using a title or technical access to exert organizational or personal pressure.

Article 53: Handling violations

The unit manager may temporarily restrict or suspend an individual’s access if a technical or security violation is observed.

The final handling of administrative or disciplinary violations is carried out in accordance with the organization’s general regulations and by the competent authority.

---

Chapter Eighteen: Final Provisions

Article 54: Supplementary Instructions

The Unit Manager may formulate and issue the following specialized instructions for the implementation of this regulation:

* Software Development Instructions
* Information Security Instructions
* Access Management Instructions
* Support Instructions
* Backup Instructions
* Project Management Instructions
* Artificial Intelligence Usage Instructions
* Code Repository Management Instructions
* Security Incident Management Instructions
* Delivery and End of Cooperation Instructions

Supplementary instructions must not conflict with this regulation or the organization's superior regulations.

Article 55: Interpretation of the Regulation

The executive interpretation of the technical provisions of this regulation is the responsibility of the Technology Unit Manager.

In the event of a dispute regarding organizational, legal, or authority issues, the opinion of the organization's superior authority will prevail.

Article 56: Amendment of the Regulation

A proposal to amend this regulation may be submitted by the Technology Unit Manager or the superior authority.

Amendments will be effective after approval by the competent authority of the organization.

Article 57: Implementation time

This regulation, in 18 chapters and 57 articles, shall be effective from the date of approval, and all procedures contrary to it shall be considered null and void from the date of implementation.

Approval date: July 27, 2026

Approval authority: Sina Torabi - Director of Technology Unit