Heights Consulting Group

Software and Application Development

Software and application development at Heights builds the web applications, internal tools, portals and integrations a business needs, with security decisions made at the requirements stage and carried through design, build and operation, so what is delivered is both fit for its purpose and defensible to the customers, auditors and insurers who will ask about it.

What you receive

Part of
Applications, portals and integrations built for the business, with security decided at the requirements stage.
Engaged as
A defined piece of work, or as part of an ongoing vCISO engagement.
Sits under
Executive ownership of the cybersecurity program.

The problem

Why this comes up

Custom software is where a great deal of risk hides. It is built to a deadline, handles the organization's most specific data, and is reviewed for security, if at all, after it already works. The result is an application everyone depends on and nobody can vouch for.

The alternative most businesses face is a platform that almost fits, extended with workarounds until it fits worse, or a development shop whose deliverable is a working feature rather than a system the business can operate for years.

The service

What this engagement is

Who it is for

  • Businesses whose process no longer fits the software they can buy.
  • Organizations that need a customer or partner portal handling regulated data.
  • Companies running critical operations on spreadsheets and email.
  • Leadership teams that want software they can evidence to a customer, an auditor or an insurer.

Design and development of web applications, internal tools, customer portals, workflow automation and integrations between systems, run by people who also lead security programs. Requirements include the security and compliance obligations the software will have to meet; design records the decisions; code is reviewed and tested against them before release.

Delivery includes what an operator needs afterward: documentation, an ownership model, a maintenance arrangement and a defined path for changes, so the application does not become the thing nobody dares to touch.

Scope

What Heights does

  • Discovery and requirements

    What the software must do, for whom, under which obligations, written down and agreed before design begins.

  • Secure design

    Authentication, authorization, data handling and logging decided in design and recorded, so the reasoning survives the people who made it.

  • Web application and portal development

    Customer, partner and staff-facing applications built to the agreed design and reviewed against it.

  • Integration and automation

    Connections between the systems the business already runs, replacing manual reconciliation and re-keying.

  • Testing and release

    Functional and security testing before release, with findings resolved rather than deferred.

  • Operation and maintenance

    Documentation, monitoring, a change process and an ongoing maintenance arrangement for what has been delivered.

Timing

When organizations engage this

  • A customer or regulator asks how the application they use was built and secured.
  • A process critical to the business lives in a spreadsheet only one person understands.
  • Two systems that need to share data are reconciled by hand every week.
  • A previous build works but nobody can safely change it.
  • A new line of business needs a portal, workflow or integration that does not exist yet.

What you receive

  • A requirements and design record that includes the security and compliance obligations
  • The application, delivered with source, documentation and an ownership model
  • Test results and a security review completed before release
  • A maintenance and change arrangement agreed for the life of the application

Alignment

Frameworks this work touches

Establishing which of these apply to you

SOC 2
An examination performed by a licensed CPA firm against the AICPA trust services criteria. Security is always in scope; availability, confidentiality, processing integrity and privacy are added when relevant.
HIPAA
The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information, including a documented risk analysis and risk management process. The Breach Notification Rule sets defined duties and timelines once a breach is discovered. HITECH extended enforcement and applies obligations directly to business associates.
PCI DSS
Prescriptive control requirements imposed through payment brand agreements wherever cardholder data is stored, processed or transmitted. Scope reduction is usually the highest-leverage decision available.
NIST CSF
A widely used structure for organizing a security program around outcomes rather than products. Its current version adds an explicit governance function, which is why it maps well onto executive-level work.

The flagship

Software carries risk the moment it handles real data. Where Heights leads the security program, the same leadership sets the standards the software is built to, so the application and the program never disagree about what secure means.

Read about vCISO leadership

First steps

How an engagement begins

The same three steps whichever service you start with.

  1. A confidential conversation

    What prompted the enquiry, what you are obliged to do, and what leadership is being asked to answer for. No cost, no obligation.

  2. Scope agreed in writing

    What Heights will do, what stays with you, the working rhythm, and how progress will be reported.

  3. Work begins

    Delivered by your team, your providers or Heights, with expectations and acceptance criteria stated up front.

FAQ

Questions we are asked about this

Broader questions about executive security leadership are answered on the vCISO page.

What kinds of applications does Heights build?

Web applications, customer and partner portals, internal tools, workflow automation and integrations between existing systems. The common thread is business software that handles data somebody has to answer for.

Heights does not build consumer mobile apps or games, and will say so when a request is a better fit elsewhere.

Who owns the code and the application afterward?

You do. Source, documentation and infrastructure configuration are delivered and belong to your organization, and the maintenance arrangement is a choice rather than a dependency.

The ownership model is written at the start, including who can change what and how a change is reviewed before it ships.

Can you take over an application someone else built?

Usually, after an assessment of what exists: the code, its dependencies, how it is deployed and what it handles. The assessment says honestly whether the application should be maintained, reworked or replaced.

Where it is maintained, the first work is often making it safe to change: tests, documentation and a deployment path, so subsequent changes are routine.

Schedule a Confidential Consultation

Four questions, answered by the person who would be at your table. If Heights is not the right fit for what you need, you will hear that in the first conversation.

In Central Florida? Make it coffee, breakfast, lunch or a drink at the end of the day. Dan buys. Say so in the message and name a part of town.

A short description is enough, what prompted you to get in touch, and what a useful outcome would look like.

Sign in to the employee portal

For Heights employees. Accounts are created by Heights; if you expected one and it has not arrived, contact us.