Security Architecture and Secure Database Design

Introduction

Database security is not achieved by adding a firewall or assigning a password to a database account. It is an architectural discipline concerned with how trust is established, how data flows through an organisation, how privileges are distributed, and how controls operate together. A secure database must remain protected when users make mistakes, applications are compromised, credentials are stolen, insiders misuse access, or services fail.

Security architecture provides the structure within which database controls operate. Secure database design applies that structure to data models, schemas, identities, queries, applications, and operational processes. The two are inseparable: a well-designed schema cannot compensate for unrestricted network exposure, and a well-segmented network cannot compensate for excessive database privileges.

This chapter develops the principles of trust boundaries, segmentation, zero-trust architecture, security by design, data minimisation, separation of duties, secure schemas, views, stored procedures, and layered protection. It also considers governance, privacy, implementation limitations, and the practical design of a secure database-backed service.

Learning Objectives

By the end of this chapter, you should be able to:

1. Identify trust boundaries and explain their security significance.
2. Design network and application segmentation for database services.
3. Apply zero-trust principles to database access.
4. Use security-by-design and data-minimisation techniques.
5. Explain separation of duties and apply it to database administration.
6. Design secure schemas, views, and stored procedures.
7. Combine preventive, detective, and corrective controls in a layered architecture.
8. Evaluate the trade-offs and limitations of secure database designs.

1. Security Architecture as a System of Controls

A security architecture is a structured arrangement of people, processes, technologies, and controls that protects information assets. Its purpose is not merely to block attacks. It must also support legitimate business activity, preserve evidence, enable recovery, and satisfy legal and organisational obligations.

A database architecture commonly includes:

• client devices and user identities;
• an identity and access-management service;
• a web or application tier;
• an API gateway or service mesh;
• database servers and read replicas;
• backup and recovery systems;
• monitoring, logging, and security analytics; and
• administrators, developers, operators, and data owners.

A useful design question is: Which component is allowed to communicate with which other component, for what purpose, using which identity, and under what conditions? The answer should be explicit rather than assumed.

Security architecture normally addresses the confidentiality, integrity, and availability (CIA) objectives:

• Confidentiality limits information disclosure to authorised subjects.
• Integrity protects information from unauthorised or improper alteration.
• Availability ensures that authorised users can access services when needed.

Other objectives are also important. Authenticity concerns whether an identity or message is genuine. Accountability links actions to responsible identities. Privacy concerns the appropriate collection, use, disclosure, retention, and deletion of personal information.

A control may support several objectives. For example, a database audit trail supports accountability and may help detect integrity violations, while encryption supports confidentiality but does not by itself prevent an authorised user from reading data.

2. Trust Boundaries and Trust Zones

A trust boundary is a point at which the assumptions about identity, authority, security controls, or reliability change. Crossing a boundary should trigger validation and enforcement rather than implicit trust.

Examples include:

• the boundary between the public internet and an organisation’s network;
• the boundary between a browser and an application server;
• the boundary between an application service and a database;
• the boundary between production and development environments; and
• the boundary between ordinary administrators and highly privileged database accounts.

A trust zone is a set of components that share broadly similar security assumptions and controls. Typical zones include a public zone, an application zone, a data zone, a management zone, and a backup zone. A zone is not automatically trustworthy; it simply provides a basis for applying consistent controls.

Trust must be understood as conditional. A user authenticated yesterday may have a compromised device today. An application server may be trusted to submit properly authenticated requests, but it should not automatically be trusted with unrestricted database administration. A database connection from an internal network should not be accepted merely because it originates from an internal address.

Boundary analysis

A practical boundary analysis identifies:

1. the asset being protected;
2. the subject requesting access;
3. the entry point and communication path;
4. the security assumptions at each component;
5. the authentication and authorisation checks;
6. the data crossing the boundary; and
7. the controls used to detect or contain failure.

Data-flow diagrams and threat modelling are useful here. For every flow, designers should ask whether the data is necessary, whether it is encrypted, whether the recipient is authorised, and whether the transfer is logged.

3. Segmentation and Security Zones

Segmentation divides systems or networks into controlled sections so that compromise of one section does not automatically expose all others. Segmentation can be physical, virtual, logical, application-based, or identity-based.

A conventional database deployment may use the following arrangement:

The core principle is that users should not connect directly from the public internet to a production database. A client request should normally pass through an application service that enforces business rules and uses a narrowly privileged service identity.

Segmentation reduces blast radius. If an attacker compromises a web server, segmentation can prevent direct access to database administration ports. If a developer account is compromised, separate production and development zones can prevent access to live personal data. Segmentation does not remove risk: a compromised application service may still misuse its permitted database privileges, so application controls and database controls must remain independent.

Microsegmentation

Microsegmentation applies fine-grained policies to individual workloads, services, or identities rather than relying only on broad network subnets. For example, an order service may be permitted to call a database service on one port, while a reporting service may be permitted only to read a reporting replica. Administrative access may be limited to a jump host and approved maintenance windows.

Effective segmentation requires attention to operational paths. Monitoring agents, backup systems, replication channels, patching services, and emergency access accounts are often overlooked. A diagram showing only the primary application flow is incomplete if it excludes these supporting paths.

4. Zero-Trust Principles for Database Access

Zero trust is an architectural approach in which no user, device, network location, or service receives implicit trust. Access is granted based on verified identity, device or workload context, requested resource, action, and policy conditions.

The practical principles are:

1. Verify explicitly. Authenticate and authorise every meaningful request using available context.
2. Use least privilege. Grant only the permissions necessary for a defined task.
3. Assume breach. Design controls so that one compromised account or component does not produce unrestricted access.
4. Continuously evaluate. Reassess sessions, privileges, device posture, behavioural indicators, and policy conditions where appropriate.
5. Protect every communication path. Internal traffic requires protection just as external traffic does.
6. Make access observable. Record relevant events and investigate unusual behaviour.

Zero trust does not mean that every SQL statement must require a human login. Service-to-service access can be automated, but each service should have a distinct identity, a defined purpose, and limited permissions. Short-lived credentials, mutual TLS, workload identity, and central policy enforcement can reduce the risks of long-lived shared passwords.

A zero-trust database request may be evaluated using factors such as:

• authenticated human or workload identity;
• requested table, view, procedure, or operation;
• source workload and device posture;
• time, location, and risk signals;
• purpose of use;
• data classification; and
• recent behaviour or policy violations.

Identity verification does not replace database authorisation. A user may be authenticated successfully but still be prohibited from reading payroll information. Similarly, an application may be permitted to create an order but not to change its price after approval.

5. Security by Design and Data Minimisation

Security by design means that security requirements are identified and built into a system from the beginning, rather than added after implementation. It includes threat modelling, secure defaults, defensive programming, secure configuration, testable requirements, and planned monitoring and recovery.

A secure design process commonly follows these stages:

1. Identify business processes, data assets, stakeholders, and legal obligations.
2. Classify data according to sensitivity and impact.
3. Map data flows and trust boundaries.
4. Identify threats, abuse cases, and failure conditions.
5. Select preventive, detective, and corrective controls.
6. Implement the controls using secure defaults.
7. Test security and resilience before release.
8. Monitor operation and improve the design over time.

Threat modelling methods such as STRIDE can help identify spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The method is useful when applied to actual data flows rather than treated as a checklist.

Data minimisation

Data minimisation means collecting, processing, storing, and disclosing only the data necessary for a specified and legitimate purpose. It has both privacy and security benefits: data that is never collected cannot be stolen from the system.

Minimisation can be achieved by:

• collecting a month and year instead of a full date when exact date is unnecessary;
• storing a token rather than a payment-card number;
• storing a derived eligibility result rather than unnecessary medical details;
• deleting temporary data after its purpose ends;
• restricting exports and retaining only approved fields; and
• separating identifying information from operational records.

Minimisation is not the same as indiscriminate deletion. Organisations must retain records required for law, audit, taxation, safety, or contractual obligations. Retention schedules should specify the purpose, owner, period, storage location, and approved disposal method.

Pseudonymisation replaces direct identifiers with tokens or pseudonyms, but the result may remain personal data if re-identification is possible. Anonymisation aims to make re-identification impracticable under the relevant circumstances; it is a stronger and more difficult objective.

6. Separation of Duties and Least Privilege

Separation of duties (SoD) distributes sensitive responsibilities among different people or roles so that no single individual can complete a high-risk process without independent oversight. It reduces fraud, accidental misuse, and the impact of a compromised account.

For a database service, responsibilities may be divided as follows:

SoD must be practical. Excessive role fragmentation can cause delays, workarounds, and shared accounts. Small organisations may use compensating controls such as dual approval, immutable logs, management review, and independent periodic reconciliation.

Least privilege complements SoD. A service account should receive only the operations it requires, ideally through specific views or stored procedures rather than broad table permissions. Privileges should be reviewed periodically, removed when no longer required, and granted through roles rather than individually wherever possible.

7. Secure Schema Design

A schema is secure when its structure helps enforce valid states, limits unnecessary exposure, and supports accountable operations. Security is not a substitute for sound data modelling, but poor modelling creates avoidable vulnerabilities.

Strong identity and constraints

Tables should use stable primary keys and appropriate foreign keys. Constraints should express business invariants that must hold regardless of which application submits a request. Useful constraints include:

• NOT NULL for required values;
• UNIQUE for values that must not be duplicated;
• CHECK constraints for permitted ranges or states;
• foreign keys for referential integrity; and
• carefully controlled cascade actions.

For example, an account status should not accept arbitrary text values if only active, suspended, and closed are valid. A database constraint provides defence even if an application validation rule is bypassed.

Classification and separation

Sensitive attributes should be identified in the data dictionary. Direct identifiers, authentication secrets, financial data, health data, and operational metadata may require different controls. In some designs, identifying data is held in a separate schema or service, while operational records use a pseudonymous customer key.

Passwords must never be stored as reversible encryption or plaintext. They should be processed using a password-hashing scheme designed for password storage, with a unique salt and an appropriate cost configuration. Encryption keys must be managed separately from the protected data and access to them must be audited.

Secure defaults

Tables and database objects should be private by default. New objects should not automatically inherit broad public privileges. Development and test environments should use synthetic or suitably de-identified data. Database configuration should disable unused services, restrict listening addresses, enforce encrypted connections, and prevent default credentials.

Safe migrations

Schema changes should be version-controlled, peer-reviewed, tested, reversible where feasible, and deployed through an approved process. Destructive changes require special care because rollback may not restore deleted information. Production migrations should be performed by controlled deployment identities rather than personal administrator accounts.

8. Views, Stored Procedures, and Query Safety

Views

A view is a saved query presented as a virtual table. Views can reduce exposure by presenting only necessary columns or rows. For example, an employee self-service view might expose employee number, department, and work contact details while excluding salary and authentication information.

Views support:

• column-level restriction;
• row-level filtering;
• stable interfaces for applications;
• simplified auditing; and
• separation between application permissions and underlying table structure.

A view is not automatically secure. Its definition must be reviewed for unintended joins, inference opportunities, and bypass paths. Users who can query the underlying tables, create unrestricted views, or alter view definitions may defeat its protection.

Stored procedures

A stored procedure is executable database logic stored and managed within the database platform. Procedures can centralise validation, transaction handling, audit events, and controlled data modification. A service account may be granted permission to execute a procedure without receiving direct update permission on the underlying tables.

Good practice includes:

• use parameterised inputs rather than concatenated SQL;
• validate values and business state transitions;
• define clear transaction boundaries;
• return only necessary fields;
• handle errors without disclosing sensitive internals;
• record security-relevant actions;
• control ownership and execution context; and
• review procedures as application code.

Stored procedures are not a universal solution. Poorly written dynamic SQL can still permit injection. Excessive procedure logic can become difficult to test and deploy. Security depends on the database platform’s execution and ownership semantics, which must be understood before relying on them.

SQL injection and parameterisation

SQL injection occurs when untrusted input changes the intended meaning of a query. Parameterised queries keep code and data separate. Input validation remains valuable, but it is not a replacement for parameterisation. Escaping rules are database- and context-specific and are less reliable as a primary defence.

Applications should use an account restricted to the operations they need. A successful injection against a read-only reporting service should not provide permission to drop tables or alter access-control data.

9. Layered Security Architecture

Layered security, or defence in depth, uses multiple independent or partially independent controls. A typical database service may have the following layers:

1. Governance layer: policies, classification, ownership, risk acceptance, and review.
2. Physical and platform layer: facility controls, hardened hosts, patching, and secure configuration.
3. Network layer: segmentation, firewalls, private endpoints, encrypted transport, and rate controls.
4. Identity layer: MFA, workload identity, privileged access management, and credential rotation.
5. Application layer: validation, parameterisation, business authorisation, and secure error handling.
6. Database layer: roles, views, procedures, constraints, row-level controls, and auditing.
7. Data layer: encryption, tokenisation, masking, retention, and controlled deletion.
8. Monitoring and recovery layer: alerts, incident response, backups, restoration testing, and continuity planning.

Controls should not be treated as interchangeable. Encryption at rest does not prevent a compromised authorised process from reading decrypted data. A firewall does not determine whether a user may view a particular customer record. An audit log does not prevent an unauthorised update, although it may support detection and investigation.

A useful control design distinguishes:

• preventive controls, which reduce the chance of an unwanted event;
• detective controls, which identify events or deviations; and
• corrective controls, which contain, recover from, or remediate an event.

For example, a least-privilege role is preventive, an alert on unusual bulk extraction is detective, and tested backups are corrective.

10. Applied Case: Secure Student Records Service

The following is an illustrative case.

Background

A college operates a student records service containing identity details, enrolment information, grades, disability accommodations, and payment status. Students use a web portal, lecturers enter grades, finance staff manage payments, and administrators maintain the platform.

Problem

The original system allows several staff members to connect directly to the database using shared credentials. The web application has broad table permissions, development uses a recent production copy, and audit records are stored on the same server under an account accessible to database administrators. There is no reliable review of bulk exports.

The risks include unauthorised disclosure, alteration of grades, misuse of sensitive accommodation information, weak accountability, and loss of evidence after an incident.

Analysis

The principal trust boundaries are the student browser–portal boundary, the portal–service boundary, the service–database boundary, and the administrator–production boundary. The records are classified into different sensitivity groups rather than treated as one undifferentiated dataset.

Threat modelling identifies several abuse cases:

• a stolen lecturer account is used to view students outside the lecturer’s courses;
• an application vulnerability is used to extract the entire student table;
• a database administrator alters a grade without independent review;
• a developer copies sensitive records into an insecure test environment; and
• an attacker deletes audit records after changing payment information.

Approach and solution

The college introduces a layered design:

1. Public access terminates at a protected gateway; the database is not internet-accessible.
2. The application tier uses separate service identities for student, academic, and finance functions.
3. Students access views and procedures that return only their own records.
4. Lecturers use a procedure that permits grade changes only for assigned courses and only during an authorised period.
5. Finance services cannot read disability-accommodation fields.
6. Administrative access requires MFA, a managed jump host, time-limited elevation, and individual accounts.
7. Production, testing, and development environments are separated; test data is synthetic or de-identified.
8. Sensitive columns are encrypted or tokenised where appropriate, with keys managed separately.
9. Audit events are forwarded to a protected logging service with restricted deletion rights.
10. Bulk exports require approval, are limited to necessary fields, and generate alerts for unusual volume.
11. Backups are isolated, access-controlled, and regularly tested through restoration exercises.

Outcome

The design reduces direct database exposure and limits the consequences of a compromised account. A lecturer’s identity can be linked to grade changes, while a finance service cannot retrieve accommodation information. The college also gains better evidence for investigations and more reliable recovery capability.

The controls do not eliminate all risk. A compromised application service may still misuse its permitted procedures, and authorised users may abuse legitimate access. Consequently, the college continues behavioural monitoring, access reviews, secure development testing, and independent audits.

Learning points

The case demonstrates that secure database design is a combination of architecture and governance. Segmentation limits pathways, least privilege limits actions, views and procedures limit data exposure, SoD limits unilateral misuse, and monitoring supports accountability. No single measure provides complete protection.

11. Governance, Ethics, and Regulatory Considerations

Database security decisions affect people, not merely systems. Excessive monitoring can invade privacy; insufficient monitoring can prevent effective investigation. Organisations should define a legitimate purpose for collection and monitoring, inform affected individuals where required, restrict access to authorised purposes, and retain evidence only as long as justified.

Important governance practices include:

• documented data ownership and classification;
• approved access requests and periodic recertification;
• privacy and security impact assessments for high-risk processing;
• retention and secure-disposal schedules;
• supplier and cloud-provider risk assessment;
• incident reporting and breach-response procedures;
• independent review of privileged activity; and
• evidence that controls are tested rather than merely documented.

Regulatory duties vary by jurisdiction and sector. Privacy laws may impose requirements concerning purpose limitation, data minimisation, access rights, security safeguards, breach notification, and cross-border transfers. Sector-specific rules may apply to education, health, finance, or government records. Compliance should be treated as a baseline; a legally compliant design may still be technically weak or ethically inappropriate.

12. Contemporary Developments and Limitations

Cloud databases, containers, serverless services, and managed platforms change where controls are implemented but do not remove the customer’s responsibility for identity, data classification, configuration, and authorisation. Misconfigured storage, excessive cloud roles, exposed secrets, and insecure service-to-service communication remain common risks.

Policy-as-code can express network, identity, and configuration rules in version-controlled form. Continuous compliance tools can detect drift, but automated findings require human interpretation. Artificial intelligence can assist anomaly detection, query analysis, and alert prioritisation, yet it may produce false positives, miss novel abuse, or expose sensitive data if used carelessly. AI systems should therefore operate under documented data-handling, access, validation, and human-oversight controls.

Secure architecture also has limitations:

• strong controls can increase cost, latency, and administrative complexity;
• too many approval steps can encourage unsafe workarounds;
• microsegmentation can be difficult to maintain as systems change;
• audit logs may create additional sensitive data and storage obligations;
• encryption complicates key recovery and lawful operational access; and
• least privilege can disrupt legitimate work when roles are poorly designed.

The appropriate objective is not maximum restriction in every circumstance. It is proportionate, risk-informed protection that preserves required functionality and can be operated reliably.

Best-Practice Design Checklist

Before placing a database service into production, confirm that:

• trust boundaries and data flows are documented;
• the database is not directly exposed to untrusted networks;
• each human and workload identity is distinguishable;
• MFA and privileged-access controls protect administration;
• roles follow least privilege and separation of duties;
• production, test, and development environments are separated;
• sensitive data is minimised, classified, and retained appropriately;
• applications use parameterised queries;
• views and procedures expose only approved operations and fields;
• constraints enforce important business rules;
• connections and sensitive data are protected in transit and at rest;
• audit logs are protected from unauthorised alteration;
• alerts address unusual access and extraction patterns;
• backups are isolated and restoration is tested; and
• access, configuration, and design are reviewed when the system changes.

Chapter Summary

Security architecture establishes controlled relationships among users, services, networks, data stores, and administrators. Trust boundaries identify where assumptions change and where authentication, authorisation, validation, and monitoring must occur. Segmentation and microsegmentation reduce blast radius, while zero-trust principles require explicit verification, least privilege, continuous evaluation, and protection of internal as well as external communications.

Security by design incorporates threat modelling, secure defaults, testing, monitoring, and recovery from the beginning of a system’s lifecycle. Data minimisation reduces both privacy exposure and the quantity of information available to attackers. Separation of duties and individual accountability reduce the risk of unilateral misuse. Secure schemas use constraints, careful classification, controlled migrations, and appropriate protection of credentials and keys.

Views and stored procedures can expose narrowly defined data and operations, but they must be implemented with safe execution semantics and parameterised inputs. Layered security combines governance, network, identity, application, database, data, monitoring, and recovery controls. The student-records case illustrates how these controls work together: no single control is sufficient, and secure design must be continuously reviewed as technology, threats, and organisational purposes change.

Key Terms

Trust boundary: A point where assumptions about identity, authority, or security change.

Trust zone: A group of components governed by broadly similar security assumptions and controls.

Segmentation: Division of systems or networks into controlled areas to limit unauthorised movement.

Microsegmentation: Fine-grained control of communication between individual workloads, services, or identities.

Zero trust: An architecture that grants no implicit trust and verifies access explicitly.

Least privilege: Granting only the permissions necessary for an approved task.

Security by design: Incorporating security requirements and controls throughout system design and development.

Data minimisation: Collecting and retaining only data necessary for a defined purpose.

Pseudonymisation: Replacing identifiers with tokens or pseudonyms while retaining a possible re-identification path.

Separation of duties: Dividing sensitive responsibilities among different roles or individuals.

Secure schema: A database structure that supports valid states, controlled exposure, and enforceable security requirements.

View: A virtual table defined by a query that can restrict rows or columns.

Stored procedure: Database-resident executable logic used to perform controlled operations.

Parameterised query: A query in which code and input data are handled separately.

Defence in depth: Use of multiple complementary security controls.

Preventive control: A control intended to reduce the likelihood of an unwanted event.

Detective control: A control intended to identify an event or deviation.

Corrective control: A control intended to contain, remediate, or recover from an event.

Blast radius: The extent of harm or system exposure resulting from a compromise.

Data classification: Categorisation of information according to sensitivity, impact, or handling requirements.

Review Questions

Short Answer Questions

1. What is a trust boundary, and why should it trigger security checks?
2. State the three central principles of zero-trust architecture.
3. How does data minimisation improve database security?
4. What is the difference between a view and a stored procedure?
5. Explain the purpose of separation of duties.

Long Answer Questions

1. Explain how segmentation, least privilege, and defence in depth work together in a database architecture.
2. Describe a security-by-design process for a new database-backed application.
3. Discuss the security benefits and limitations of using views and stored procedures.
4. Explain how secure schema design can support confidentiality, integrity, and accountability.
5. Design an access-control model for a database containing student, finance, and health-related records.

Analytical / Application Questions

1. A reporting service has read access to every table in a production database. Analyse the risks and propose a redesigned architecture using roles, views, procedures, and segmentation.
2. An organisation wants to copy its production database into a development environment to accelerate testing. Evaluate the proposal and recommend a secure alternative.
3. A database administrator can create accounts, alter data, and delete audit logs. Analyse the separation-of-duties weaknesses and design compensating controls for a small organisation.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a trust boundary?

A. A point where assumptions about identity or authority change

B. A backup copy stored in a separate location

C. A database table containing trusted records

D. A physical cable connecting two network switches

Correct Answer: A. A point where assumptions about identity or authority change

Question 2

What is a primary purpose of network segmentation in a database architecture?

A. To eliminate the need for authentication

B. To reduce the blast radius of a compromise

C. To make all internal traffic trusted

D. To replace database constraints

Correct Answer: B. To reduce the blast radius of a compromise

Question 3

Which principle is central to zero-trust architecture?

A. Trust all internal users by default

B. Permit access permanently after the first login

C. Verify access explicitly and grant least privilege

D. Allow database access based only on IP address

Correct Answer: C. Verify access explicitly and grant least privilege

Question 4

Which practice best demonstrates data minimisation?

A. Collecting every available customer attribute for future use

B. Retaining all records indefinitely

C. Storing only the month and year when an exact date is unnecessary

D. Copying production data into every test environment

Correct Answer: C. Storing only the month and year when an exact date is unnecessary

Question 5

Which control most directly supports separation of duties?

A. One administrator approves and deploys their own change

B. A developer and an independent approver perform separate release activities

C. All employees use one shared database account

D. Users receive access without periodic review

Correct Answer: B. A developer and an independent approver perform separate release activities

Question 6

What is a major security advantage of a carefully designed database view?

A. It automatically encrypts every database backup

B. It can expose only approved rows and columns

C. It prevents all forms of SQL injection

D. It removes the need for access control

Correct Answer: B. It can expose only approved rows and columns

Question 7

Which practice is the most appropriate defence against SQL injection?

A. Concatenating user input after removing spaces

B. Using parameterised queries

C. Granting the application administrator privileges

D. Relying only on client-side validation

Correct Answer: B. Using parameterised queries

Question 8

Which is an example of a detective control?

A. A least-privilege database role

B. A firewall rule blocking an unauthorised port

C. An alert for unusual bulk extraction of records

D. A tested backup used after data loss

Correct Answer: C. An alert for unusual bulk extraction of records

Question 9

Why should development and test environments generally be separated from production?

A. To ensure developers can access live data freely

B. To prevent testing from affecting live services and reduce data exposure

C. To remove the need for change management

D. To make production credentials reusable

Correct Answer: B. To prevent testing from affecting live services and reduce data exposure

Question 10

Which design most closely follows least privilege for an order service?

A. Granting full database-owner permissions

B. Allowing direct access to every production table

C. Allowing execution of narrowly defined procedures required for order operations

D. Using a shared administrator password rotated annually

Correct Answer: C. Allowing execution of narrowly defined procedures required for order operations