Rules of Procedure

Project Policy

Adopted by the Board on 28-Sept-2021


Projects are central to OWASP’s mission of achieving and promoting proper application security. This policy defines the rules related to starting, running, maintaining, and dissolving OWASP projects.

Project Leadership

Project leaders serve as the main point of contact for their projects and are responsible for ensuring the project complies with all OWASP policies while fulfilling its mission and obligations.

  • Project leaders are not required to be members, but it is recommended to become one to promote membership.
  • Project leadership is open to all participants. Leadership is personal, and not associated with any organization, company, or employer.
  • Each project must have a minimum of 2 and a maximum of 5 foundation-recognized, official leaders. In the event of a resignation, leadership transition, or new leadership being appointed, a project is allowed a grace period of up to 3 months from the event to comply.
  • A project leader should strive to be a leader of a small number of projects; spreading yourself too thin will likely lead to project failure.
  • Leaders will sign and return a leader’s agreement within 30 days of receipt if one is presented.
  • Each leader will annually confirm upon request within 30 days that they intend to continue volunteering as project leader.
  • Leaders are encouraged to transition or rotate when they are unable to devote sufficient time to a project to allow fresh leaders to step up and participate in the project operations. Leader selection is at the project’s discretion, provided all policies are followed.
  • If a project’s leadership does not have consensus, fair and open elections should be administered with the support of OWASP staff and the Project Committee.
  • If a leader is no longer reasonably responsive and contributing to the project, the remaining project leaders or prospective leaders may petition the leader’s removal in accordance with the dispute resolution process.

Running a Project


Projects must be discoverable by new and existing members and participants.

  • Project activities must appear on the website.
  • It is required for new projects to use OWASP’s official project source platform. Existing projects and new projects requiring an exception may request one.
  • Each project is responsible for creating and maintaining their project home page (see also Starting a New Project and Activity Requirements).
  • Projects must identify as an OWASP project in their branding.
  • A list of the current leaders and email addresses must be listed on the Project’s web page on It is highly encouraged that leaders use their email address on these pages.

Activity Requirements

  • Contributors do not need to be members. All members of the public are allowed to participate in OWASP projects.
  • Project meetings must be free.
  • Projects should endeavor to produce a minimum of 1 release a year to maintain an active OWASP project.
  • Project activity information (date and version) must be posted on the project page.

The Project Handbook[TBD: Needs Link] contains details of how to run a project and find contributors.


OWASP is a social community, and we need to communicate with our community regularly.

  • Project leaders should use email address for all OWASP related correspondence.
  • Project leaders should monitor their email address regularly and respond within 9 business days.
  • Requests from OWASP staff, such as expense claims, should be responded to by one or more of the project leaders within 9 business days.
  • Leaders are encouraged, but not required, to monitor and participate in the OWASP Leaders List, other Google groups, and the Slack platform.
  • OWASP projects can create and manage their own social media presence and other reasonable communication channels. Access to these accounts must be shared with all leaders of the project. Administration of the account should be handed over to a remaining project leader when stepping down.

We recommend project leaders set an out of office notification within their email if they are planning to take leave, so that project members, the Project Committee, and foundation staff are aware of any absences or delays in responding to communications.

Shared Services

OWASP Foundation will provide projects with the following shared services at no cost. Projects are encouraged to make use of these. Access to these services can be obtained by submitting a ticket via Contact Us. If, after 9 business days have passed, and reasonable efforts have been made to attempt to utilize shared services, no response is received, the project may, with due care, seek a reasonable alternative, filling out a Project Funding Pre-Appoval ticket. [TBD - Grant Funding pre-approval]

  • Project page on the website.
  • Video conferencing and webinar facilities for virtual meetings and events, and hybrid in-person / virtual events.
  • Social messaging app to communicate in real time with the OWASP community.
  • Leaders have access to [email protected] - join using email address.
  • Assistance and resources are available through the Project Committee and other OWASP Committees.
  • Event insurance covering project meetings.

Services identical or similar to those provided by the foundation cannot be expensed without prior approval. Where possible, all projects are encouraged to use a service that respects user privacy.

Starting a New Project

There are currently three types of projects you can start: tool, code, and documentation. Prospective project leaders should familiarize themselves with this policy and the Project Handbook (TBD) prior to submitting the New Project Request Form.

  • New projects must be approved by the foundation, by submitting a request through Contact Us.
  • After the new project is approved, the project leader must:
    • Create new project pages within 30 days of GitHub access on the website (see Website Migration Information and Tutorial for assistance).
    • Log into their email account within Google’s defined time period, or they will need to log a support ticket via Contact Us to have a password recovery email sent to their registration email address.
  • Projects under the OWASP umbrella are the combined efforts of the project leaders, contributors, and the OWASP Foundation. All source material must remain within the foundation. However, as these are open source projects, people are not prevented from forking projects and beginning new, non-OWASP projects. Removal of all project source material is at the sole discretion of the foundation.
  • Projects must select a license that provides the public free open access to project source materials and distributables. The license should be communicated in the GitHub LICENSE file.
    • Source code and build artifacts must use an OSI-approved open source license.
    • Documentation source and artifacts must use a Creative Commons license, or an open license from an international standards organization.
    • Any exceptions to be above must be approved by the Project Committee.

Contributor Agreement

Projects must use OWASP’s recommended contributor agreement, DCO to ensure that all contributions are the original work of the contributor and/or they have permission to contribute that code or change. Projects with an existing contributor agreement are exempt from this policy as long as the contributor agreement doesn’t conflict with OWASP’s license requirements, copyright assignment requirements, and covers the risks of plagiarized code.

Renaming a Project

  • Any project name changes must be approved by the foundation. A request for approval must be submitted through Contact Us.


  • Projects may request subdomains of the format OWASP does not cover the cost of existing domains that are not a sub-domain of unless those domains redirect to an official Expenses will not be paid for any other domain held by a project.
  • OWASP branding (including OWASP logo, links to the official website, project home page, and repo) should be prominent on sub-domains or alternative domains maintained by the project. This branding should adhere to the OWASP Branding Guidelines.

Inactive Projects

The OWASP Foundation aims to provide continuity for OWASP project members. The following process is to determine inactive projects and try to install fresh leadership.

  • An inactive OWASP project is a project that has not met minimum activity requirements defined in this policy.
  • An inactive project must either be reactivated or dissolved.
  • The OWASP Foundation will revoke the inactive project leadership and refer the inactive project to the Project Committee to help find fresh leadership or to run elections to elect new leadership.
  • Use the starting a new project form to reactivate a project.

Finances, Oversight, and Transparency

Projects are overseen on an operational basis by the Project Committee, the OWASP Foundation staff, and, ultimately, the OWASP Board of Directors. If the Project Committee, foundation staff, or board of directors determines that a leader has not complied with this policy, despite support and outreach, leadership may be revoked, suspended, or another action taken. Additionally, OWASP administrative access (including the leader’s email address) may immediately be revoked.

Code of Conduct and Other Relevant Policies

All leaders must follow and adhere to all OWASP Foundation policies and procedures, which are in a central repository. As a US-based 501 (c)(3) non-profit organization, OWASP must follow specific financial and legal guidelines that can change from time to time.

Projects operate with a great deal of freedom; however, projects must abide by the latest approved Code of Conduct, Foundation Bylaws, and these policies and procedures. Copies of older versions are not relevant.


OWASP membership and participation in project meetings are subject to locally applicable data protection regulations (for instance, see GDPR). Where conflicting local regulations exist, the most restrictive should be observed. Any project meetings must comply to OECD principles; the Collection Limitation Principle applies to all activities where personal information of participants is needed. Project leaders are not permitted to share member lists or private information with third parties except where operationally necessary and only after informing relevant parties with opt-in acceptance. Projects should, where possible and not otherwise required by local legislation or compliance requirements, adopt a data minimization approach, and delete data that is no longer necessary.

Submitting Expenses

Project related expenses incurred while holding a project meeting within the geographic area of the project itself must comply with the expense policy and must be submitted within 60 days.


Memberships must be processed per the membership policy


All donations must comply with and be processed per the foundation donation policy.

Projects wishing to create paid events like training and workshops should review the events policy for more information. Payments for training, workshops, and other events will be made in accordance with the expense policy.

Chapters, projects, and groups are not legal entities and are organized under the OWASP Foundation’s authority.

Finances are via OWASP Foundation Only

As projects are not legal entities, all membership dues and funds must be processed through the foundation for transparency, the US not-for-profit laws, regulatory, and tax compliance reasons. Projects are not permitted to hold any bank accounts, independent insurance, have an independent donation mechanism, or use any funds transfer mechanisms to store financial value such as gift cards, PayPal or Venmo, or any other banking or financial instruments.

Signing Authority

Projects operate under the aegis and policies of the OWASP Foundation and are subject to the OWASP signing policy. As non-legal entities, project leaders and members of projects cannot sign contracts or enter into agreements with commercial organizations. All such agreements should be referred to the OWASP Foundation for pre-approval and possible signing.

Supporters and Bartering Arrangements

Projects are encouraged to obtain local project supporters via bartering arrangements (i.e. services, event spaces, or food and beverages are paid for by a project supporter) and donations via the OWASP website. Projects can define levels and benefits of local Project Supporters, including logos on introduction slides and the Project home page. Any contractual agreement, bartering arrangement, or financial transaction must be registered and processed by the Foundation through our service desk


OWASP has various dispute resolution mechanisms. Please contact the Compliance Committee if you are unsure of reporting a complaint or raising a dispute. In general, disputes should be resolved between parties and not in the court of public opinion on social media or mail lists.

Project members and leaders can use the following policies and reporting mechanisms to resolve disputes or to report code of conduct breaches, violations of policy, or financial requirements:

Sanctioned Countries and Leaders

OWASP must comply with international laws and regulations, including international sanctions. Sanctions take many forms and are often limited in scope to access to specific intellectual property, organizations, governments, and/or individuals.

From time to time, the Executive Director and Community Manager will review sanctions from the EU, USA, and anywhere else the foundation has an operating entity, and apply the following policies.

Until sanctions are lifted and where not complying with or breaching sanctions would cause the OWASP Foundation to be subject to fines, civil or criminal liability, the following policies will be applied:

a) New projects cannot be formed. b) Existing projects may be disbanded or made independent of the Foundation depending on the nature of the sanctions. c) Leaders and members who are sanctioned individuals will be removed from any leadership positions, and any membership fees refunded, including Lifetime membership. d) Access to OWASP materials is free and open-source, and can be obtained through many means, including OWASP’s shared cloud platforms. For the purposes of curtailing access or prohibiting the “export” of such freely available information, OWASP relies solely upon the technical controls in place by our shared cloud platforms, which share the same sanction controls as the OWASP Foundation. The Foundation has no control over these technical controls, and the Foundation will not subvert these technical controls to allow access in sanctioned countries.

The Executive Director and/or Project Director will inform the OWASP Global Board and Project Committee of any changes to sanctioned projects, leadership, or access.

The Community Manager will review the list of sanctioned chapters and leaders periodically to determine if the Foundation can restore the project, leadership, and membership.